On 10/4/06, Christopher Aillon <caillon@xxxxxxxxxx> 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
