AWOL Maintainer: Krzysztof Kurzawski

[Vasile Gaburici]

+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 at gmail.com>:
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>