AWOL owners and stale packages.

[Michael J Knox]

Hello Michael,

Thanks for commenting...

Michael Schwendt wrote:
> On Fri, 12 May 2006 14:48:47 +1200, Michael J. Knox wrote:
> 
>> This is a request for comment and perhaps an informal proposal for how 
>> to handle packages with AWOL owners.
>>
>> I have spent sometime discussing this process with a work college, a 
>> debian developer, on how best practice and the appropriate etiquette 
>> could be shown to the current owner of a said package. He suggested that 
>> debian's NMU or Non-Maintainer Upload, processed worked well within the 
>> debian development community.
>>
>> I have read through this policy of debian's and think that it addresses 
>> the issues nicely of ensuring that packages are not left to become stale 
>> and not offend packager owners.
>>
>> I am proposing we (Fedora Extras) adopt the same process. It would need 
>> to be made Fedora relevant and I would hope that people will see the 
>> plus in such a process.
>>
>> The over all aim is to avoid "stale" packages in Extras, more swiftly 
>> pick up on unmaintained packages and hopefully encourage people to work 
>> on these packages by providing a process in which people can fix them.
> 
> First of all, I think you mix a few things. Specifically, the NMU talks
> about "fixes", "bugs" and "serious problems", while you talk about
> "stale", "unmaintained" packages and "the take over of a package". Not
> sure whether you want to merge all that into a single policy.

Possibly, I sort of see them one in the same. The "fixes, bugs and 
serious problems" can only apply if the package owner has been contacted 
and had no response.

I see it as more of a taking small steps to ownership on a package where 
the original owner is no longer contactable.

> 
>     The main reason why NMUs are done is when a developer needs to fix
>     another developer's packages in order to address serious problems or
>     crippling bugs or when the package maintainer is unable to release a
>     fix in a timely fashion.
> 
> I find that description poor. It is not clear when and why "another
> developer's packages" are touched without the package maintainer doing
> it. Because as soon as developers talk to eachother (e.g. in bugzilla),
> collaborative package development becomes possible without additional
> bureaucracy. Packagers at FE have done this multiple times before for
> rebuilds, fixes and even version upgrades. If the NMU is only about
> unreachable maintainers, the Debian folk has added a lot of bureaucracy
> and complexity with questionable benefit and increased requirements for
> tracking (e.g. that applied changes are not reverted the next time the
> maintainer returns and imports his own package).

Yes, debian has added too much bureaucracy... but I wont start on that.

This is not intended to impact active packagers. If people have issues 
with an active packagers package, then file a bug ;)

> 
> Noticably, the NMU is independent from what the security team does.
> 
>     When a security bug is detected, the security team may do an NMU,
>     using their own rules. Please refer to Handling security-related bugs,
>     Section 5.8.5 for more information.

As is QA from security in FE (independent)

> Here are the sections on dealing with MIA/AWOL maintainers:
> 
>   Orphaning a package
>   http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-orphaning
> 
>   Adopting a package (!)
>   http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-adopting
> 
>   Dealing with inactive and/or unreachable maintainers
>   http://www.debian.org/doc/manuals/developers-reference/ch-beyond-pkging.en.html#s-mia-qa
> 
>   Collaborative maintenance
>   http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-collaborative-maint
> 
> What we most certainly don't want is that arbitrary developers use a
> procedure like the NMU to do version upgrades without good reason. I like
> that the NMU requires developers to file bug reports (including unified
> diffs) for the changes they plan to apply.

Version updated should not be allowed unless no other means of fixing a 
bug is possible.

There *has* to be a BZ trail from the person wanting to do the NMU. As 
Glenn, my work college, told me, it is expected that a NMU is announced 
on debian's mailing list before it happens.

This creates peer review and helps prevent "sneaky" upgrades and hi-jack 
attempts.

> And if a package maintainer is believed to be MIA/AWOL, we don't want that
> arbitrary developers use this opportunity to do upgrades without the
> package getting a new maintainer. The NMU requires developers to watch
> incoming bug reports, since their changes may cause new problems. This
> adds quite some complexity to the package maintainership model.

The NMU process I am proposing is to allow someone to take over that 
package (slowly and proven) not to run wild over CVS and the buildsys 
hap hazardly.

AWOL owner --> Bob starts a BZ trail --> files patches --> announces NMU 
--> NMU pushed out ---> Bob requests ownership --> FESCo gives thumbs up.

That's how I see the process.

>> An example would be:
>>
>> http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01763.html
> 
> Start tracking the date and number of contact attempts inside the bugzilla
> ticket. Mention whether your email bounced. Announce that you plan to take
> over the package next week. See below.

Agree. the BZ trail is the up most importance in a process like this.

>> This also allows people to demonstrate that they have a willingness to 
>> maintain a package and are capable of doing so.
>>
>> You can review debian's process here:
>>
>> http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-nmu
>>
>> Some items that would need clarifying, would be the time needed to be 
>> considered "reasonable" in the time of contact and delay. Also, there 
>> would need to be persons responsible for "approving" the take over of a 
>> package.
>>
>> Please note, this is not to address or replace the orphan process, but 
>> to help in cases where the package has not been orphaned and the 
>> maintainer is not contactable.
> 
> Too much at once. If a maintainer has not responded for more than six
> weeks (as in the given example where a build is missing!), it should be in
> the maintainers best interest that somebody else takes over package
> development. And we ought to start tracking maintainers, which are
> believed to be MIA/AWOL.

Ok, but this process is missing and sometimes best intentions with out 
process lend to offending developers and standing on toes.

Also, no one has told this person they could do that. Well, not that I 
have seen.

>> If a process like this is received well, then I am happy to draft it for 
>> FESCo to ponder.
> 
> What I don't like at all is the uncertain package status and ownership.

Likewise, I wanted feed back (which you have given :) ) to help close 
the loop holes and define the process

> Packages without a maintainer, but which are touched occasionally by
> arbitrary people. With the next big problems inside the package and nobody
> interested in contributing maintenance, we would be back at the drawing
> board, since the package is still without maintainer/owner.

This isn't a silver bullet proposal, merely a proposal on up to handle 
the situation when it arises. Its not going to provide a catch up for 
all state/unmaintained/AWOL developers, but it will allow those who see 
a package go stale and are willing to take it on with a defined process 
to do so.

> I would appreciate if we started bottom-up with a procedure for "Adoption
> of Packages" and the corresponding tracking of MIA/AWOL maintainers. Then
> we enhance the procedure in order to permit certain actions (like
> requesting (re-)builds, fixing grave bugs) while it is still being waited
> for a response by the maintainer. It will probably, except for security
> issues, look like:
> 
>   - notify maintainer
>   - wait X days
>   - notify maintainer about planned take-over and 
>     planned actions [e.g. (re-)builds, fixes]
>   - wait another X-Y days
>   - touch the package
>   - maybe wait another Z days
>   - take over the package in owners.list
> 

Thats exactly what I was meaning. But its important that the "X, Y, Z" 
time frames are well known and defined.

Michael