Christoph Wickert wrote:
And this is exactly the scenario that we were trying to address when we decided that two weeks from the *formal start* of the procedure was appropriate. There is a long lead time before the Non-Responsive Maintainer policy actually gets invoked where you don't know that the maintainer is non-responsive. Meanwhile the package is languishing.Am Montag, den 11.08.2008, 09:01 +0200 schrieb Karel Zak:Krzysztof, please respond to this mail or to bug 446883 within 2 weeks,2 weeks? It seems you are really inpatient :-)Not really: * Package is broken since F9 release (I guess even before, but nobody realized). * Bug was opened 2008-05-16. * Trying to contact Krzysztof for a month now. This means 6 weeks in total.
After the recent discussions around mether's draft of additions to non-responsive maintainer, though, I'd be inclined to say, shorten this period even more but make it into a forced co-maintainership instead of an orphan and re-adopt. ie: instead of two weeks + a one week comment period. Have a two week period of combined wait for maintainer response and comments from another party. Once that expires, the other packager is made a comaintainer of the package and can commit fixes, deal with bugs, etc. If the maintainer reappears, he'll find notices in his INBOX that the package has been assigned a new comaintainer according to the policy.
What this gives us:1) More maintainers of packages. If the original maintainer comes back, are they going to be happy or angry that all the bugs they had before they went on their month long vacation have been addressed? Are they going to be upset that users of the package cared enough about it to volunteer their time to co-maintaining it?
2) We still have a watch on essential packages via the combined comment period. If all the kernel maintainers go on vacation and someone starts the process, do you expect that no one's going to say, "wait a minute... really?!"
3) Similarly, if you are going on an extended vacation but don't want the general public to know, you still have to make sure that your packages are taken care of by someone while you're gone. Maybe a coworker has access. Maybe acls are opened to the packager group. Maybe you want to grant a few friends access/permission to modify your package. If you did work on someting really important like the kernel and no one else had access but you and you went on vacation, would you really not leave someone else with permission to modify the package in your absence? If your package was trivial would you really be so controlling that opening to the packager (or uberpackager shortly) group would not be okay?
4) Helps us identify weak spots in our maintanance: If all the kernel maintainers did go on vacation for the same four weeks wouldn't that point out that we absolutely must have more people working on the kernel even if it isn't the person who started the process?
5) Quicker care for packages. If the consequences are no longer phrased as punishment (I'm going to take your package away from you) but as help (You aren't answering bug reports or private mail, I'm going to send a message to fedora-devel to ask to comaintain this with you)
What this burdens us with:1) We need to pay better attention to what gets entered into this process. We should probably record the information on a status page (or web app...I'll volunteer to write this if it's felt that's needed) and send messages out to all the people listed on the package in any way and possibly to fedora-devel-announce.
2) If there's someone who tries to become a comaintainer everytime someone goes on vacation or doesn't answer a bug they've filed we should have a note in the policy that their comaint requests can be rejected if they continue.
-Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
