AWOL owners and stale packages.

[Michael Schwendt]

On Sat, 13 May 2006 10:10:58 +1200, Michael J Knox wrote:

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

Okay. That, of course, is quite different from [and more detailed than]
"avoiding stale packages".

I just wanted to make sure that the reason for NMU-activity is given in
_actual problems_ with a package and not just due to some contributors
preferring to engage in a release-race with upstream. Those tickets like
"version 1.2.3 is available, please upgrade", which are easily forgotten
by packagers, who didn't like a new release when they evaluated/tried it.

"Unmaintained packages" was another vague term you used above, which I
didn't comment on. _Packages without a maintainer_ (= orphans) can be
taken over very "swiftly", because there is no maintainer you need to try
to contact. Hence no need for complicated policies in that area.

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

Right, and where a package is broken. That's exactly where we should
start.

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

Let's start with X, maximum packager response time for a bugzilla ticket,
in which a serious (or normal) bug was reported. Would X=14 days be too
short? X+Y would cover at least two weekends. I mean, if a packager is on
a long vacation (several weeks or more) and is neglecting package
maintenance knowingly, the package would be suitable for shared
maintainership anyway. And in cases where a packager has had an accident
or is facing temporary illness (and similar things), we're back at what
I've written before -- that it should be in the packager's best interest
that other contributors help.