AWOL owners and stale packages.

Michael J Knox michael at knox.net.nz
Tue May 16 08:04:13 UTC 2006


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




More information about the fedora-extras-list mailing list