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
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
