Re: Do not make gratuitous source uploads just to provoke the buildds!
On Wed, 16 Mar 2005 14:44:34 +0100, Wouter Verhelst <email@example.com> wrote:
> Op di, 15-03-2005 te 16:19 -0500, schreef Anthony DeRobertis:
> > Wouter Verhelst wrote:
> > | You misunderstood. I don't fight generic changes to the order; I just
> > | don't think it would be a good thing that any random developer could
> > | prioritize his pet package.
> > |
> > Any random developer already has root on X thousand debian systems. We
> > can trust him with that, but not with helping determine build order?
> I'm afraid it won't actually be 'helping'.
> I've seen enough of "My package isn't built and it's urgent and the
> buildd admins suck!" to expect what would happen.
Aah, so the trick should be to implement this on the quiet. Tweak the
values according to have it's progressing. Eventually you should see a
reduction in complaints. It wouldn't be hard to be able to guarentee
an upper bound for building, say two months. Once people stop
complaining you can tell them. Maybe they won't feel so inclined to
fiddle when they can see it works.
> That's not to say that a request to prioritize a package is to be
> ignored; however, the power of deciding which packages get built first
> should be with those that actually build the packages, rather than with
> those who want their packages to be built. The former are expected to be
> following the larger picture; the latter are not.
As far as I can tell, buildd admins don't spend all day prioritising
builds manually anyway. We're dealing with computers here, they don't
care how complicated the calculations are. Decide where your
priorities are and implement it. If you don't like to hear people
complain, add a rule saying "if package is older then one month, build
it now". It cost you nothing and saves heaps of grief. As a bonus,
repeatedly uploading new versions would keep resetting the counter, so
they'd be encouraged to upload less.
The current process of indefinitly starving "extra" packages is just silly.