Michael Schwendt wrote:
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".
Ok, sorry... sometimes I assume everyone is on the same page as me and
neglect to make sure that I am understood :)
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.
No way. This isn't about version bumps. The "version 1.2.3 is available,
please upgrade" doesn't or shouldn't apply here. This is only about the
process of handling packagers when an owner gives zero response and is
not seen to be active. Avoiding the need for yourself and others to
orphan them and disable their builds.
"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.
Thats only if the previous owner has announced as an orphan and noted
that on the wiki or someone, like yourself, has figured out that no one
is maintaining and orphaned it.
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.
agreed
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.
I feel, that if an owner is considered "active" then he/she should be
able to at the very least, acknowledge a form of contact, direct email
or BZ, within a 3 week time frame.
However, I think it needs to be more than one attempt over that time
frame. The person attempting the NMU must provide "proof" IMHO in the
form of BZ reports etc of these attempts.
A formal accounacment of intent on the extras list would be required, in
case someone on the list knows the current owner where abouts.
Michael
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
