AWOL owners and stale packages.
Michael Schwendt
bugs.michael at gmx.net
Sat May 13 18:42:01 UTC 2006
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.
More information about the fedora-extras-list
mailing list