AWOL Maintainer: Krzysztof Kurzawski

[Toshio Kuratomi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080811/474a6e1f/attachment.bin