+1 It can take several weeks for an orphaned package to be reinstated, especially if the new packager is not yet sponsored. Yes, shameless plug :0 2008/8/12 Toshio Kuratomi <a.badger@xxxxxxxxx>: > Christoph Wickert wrote: >> >> 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. >> > 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. > > 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 > > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
