Dear Fesco: Orphan package process needs work

Jeff Spaleta jspaleta at gmail.com
Wed Oct 4 21:05:14 UTC 2006


On 10/4/06, Christopher Aillon <caillon at redhat.com> wrote:
> In either case, something is broken.  If a package doesn't get a fair
> chance to be picked up before dropped, I'd say that's broken.  Or, if an
> auxiliary process such as mass rebuilding gets free reign to ignore
> other processes, then that is broken.

we are talking about the development tree.... even core-development
tree does not claim to be in a self-consistent state from day-to-day.
If extras-development is broken because of a mandated pull of a build
due to maintainer inaction.. I say good... the sooner we catch
problems with maintainer miscommunication or inaction the better.

The reality is that preparing for a release tree is going to always
run into time constraints associated with any process which allows for
iterative communication with inactive maintainers. Even if Davidz's
email saying he'd take care of it restarted the clock... there's no
garuntee he'd have taken care of it if we gave him a second chance, or
a third chance... or a fourth chance. The longer the project waits on
a deliquint maintainer to take promised action, the more pressed for
time a new maintainer will be  when corrective action is needed to
meet the release tree deadline. This must be avoided... and if
breaking the dependancy chain in the development tree is the reality
check that keeps maintainers honest with each other on how to share
the workload..then so be it... the package pull has served its purpose
and put the problem into focus for all the effected maintainers who
were relying on davidz to take the action as promised.

The current policy was explicit and honest. If the maintainer in
question hadn't responded with a promised action we may have had a new
maintainer step up before the clock expired without running into time
constraints associated with the release timing.  Because davidz
promised to take action and didn't, the only way we knew a new
maintainer needed to take over was because the package was pulled.
If anything was broken in the process, it was accepting the 'i'll take
care of it' response without a latching interium deadline as
sufficient to prevent a new maintainer from being assigned when this
was first brought up.

-jef"simple rule, don't say you are going to do something unless you
are actually going to do it. Hard deadlines are there specifically to
catch these sort of things. Expecting the process to repeatly slip to
make up for individual inaction subverts the larger scheduling and
workload maintainence demands."spaleta




More information about the fedora-extras-list mailing list