AWOL owners and stale packages.

[Michael Schwendt]

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.

    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).

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.

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.

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.

> 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.

> 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.
 
> 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.

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.

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