Make rcross a co-maintainer for update_advanced

Thanks for the offer! Sure, I'd be happy to have a co-maintainer for this module. It's true I don't have much time for it anymore...

However, I haven't seen you participate in the queue here yet, so I don't know how careful and thorough you are, what kind of code you write, how you handle Git, etc. I don't want to just make you a co-maintainer without some sense of those things. So, maybe the first step would be posting some reviews of the patches you'd plan to commit, and perhaps uploading some patches for issues that don't have them which you'd like to fix. How does that sound? I'm re-titling this issue so it's got a more self-documenting name (since I'm involved in a lot of issues) and tentatively calling it "postponed" until I've seen some of your issue participation and code, first.

I'm glad you don't think this module needs a lot of bloat. That's important to me, too. Mostly I think this should be small and simple. I haven't seen Update Detailed Email yet, so I don't know if it's a good idea to merge it in here or not. If that's a good idea, let's talk about it in a separate issue.

Thanks!
-Derek

Yeah, we might have met in person, but that still doesn't mean I know what your code smells like. ;) Agreed that an official 7.x-1.0 release would be a good idea. See #1779280: Create D7 release of Update status advanced settings for tracking progress on that. In fact, another thing that would be useful would be updating the summary there with what you think are the blockers for the release.

Thanks!
-Derek

@dww: Many weeks ago I send you an email about the same question? Have you received my email to co-maintain the module?

@hass: Sorry, I think I saw it when it first came in, but that was a bad time for me, I couldn't deal with it in that moment, and it quickly got buried in my inbox. Since there was no issue about it, it was just lost and forgotten. Apologies. I just opened #1896228: Make hass a co-maintainer for update_advanced so your request doesn't get lost again. Let's continue the discussion there.

Thanks/sorry,
-Derek

p.s. In submitting that issue, I realized the "(maintainer needs more info)" part of this status is probably more appropriate for both issues. ;)

@rcross:

A) Please see the list I made for hass at #1896228-2: Make hass a co-maintainer for update_advanced for things to be careful about, and especially see comments #5 and #6 there so you don't make the same mistake. ;)

B) hass thinks the 7.x-1.x branch is now ready for a release. Please see #1779280: Create D7 release of Update status advanced settings. Do you agree? Anything else need fixing before rc1? 1.0?

Thanks!
-Derek

Maybe it's time for tagging a legit 1.0, or an 1.x-rc2?

Then +1 to add an additional maintainer (2 years later). It's time some projects move forward.

there is one critical fix we require in core and nobody reviewed it in past 2 years. Without this committed to core this module does not work properly.

hass, what is the core issue? Do you have a link?

FWIW, I have been using this module for years and have not noticed any major problems. Ignoring updates for enabled projects seems to work fine.

Found it: #1951408: Core Update manager doesn't correctly handle "status" UPDATE_NOT_CHECKED

If I recall correctly, the issue only affects the Update tab of Update Manager. So if you do not use the Drupal web interface to install modules (e.g., using the Update tab), there would be no problem. Please correct me if wrong.

For the use case of suppressing e-mail notifications for particular module updates, the module works fine (aside from couple open bugs in this project). I believe the module also works for ignoring updates as seen by Drush.

Correct. That is the case. I know all other stuff is working, but this issue is really a blocker for final.

The main function of the module is to set Update Manager to ignore certain projects. Since that only works partially, the module is incomplete. If there were a full release, administrators may be given the false impression it is functionally complete. So to me at least it seems reasonable to consider #1951408: Core Update manager doesn't correctly handle "status" UPDATE_NOT_CHECKED a full-release-blocking issue.

Edit: An alternative solution might be to narrow the scope of the project-ignore functionality to only ignoring update notifications. (Or at least clarify that it only affects update notifications.)

+1 for 1.0 goal to be about limiting notifications, which is useful for sure. A note about ignoring performance and a blocker for 2.x sounds reasonable. 1.0's never need to have everything, that's why they're "1.0's". ;)