Re: Do not make gratuitous source uploads just to provoke the buildds!
Wouter Verhelst <wouter@grep.be> writes:
> Op ma, 14-03-2005 te 17:59 +0100, schreef Goswin von Brederlow:
>> Wouter Verhelst <wouter@grep.be> writes:
>>
>> > Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
>> >> The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
>> >> sorted by:
>> >>
>> >> - target suite
>> > - previous compilation state (already built packages are prioritized
>> > above packages never built for the target architecture)
>> >> - package priority
>> >> - package section
>> >> - package name
>> >>
>> >> I personally believe it would be beneficial to prioritize by upload urgency
>> >> as well (probably as a sort criterion between package priority and package
>> >> section), but the w-b maintainers disagree.
>> >
>> > I agree with the w-b maintainers. The queue order is only interesting in
>> > the case where there is a backlog; in other cases, packages are usually
>> > built rather fast. In the case where there is a backlog, those trying to
>> > fix the architecture (usually those that are working on it) should be in
>> > charge of deciding what package gets built first, not the maintainer of
>> > a random package -- /all/ package builds are urgent if there's a
>> > backlog.
>>
>> Since you think an empty queue is normal why then fight changes to the
>> queue order?
>
> 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.
My suggestion is to use an aging algorithm with "time * alpha +
beta". Aspects of a source would then affect alpha and beta.
Example:
- Essential: yes adds 100 to beta and 5 to alpha.
- Urgency: critical adds 10 to beta and 1 to alpha
The package with the highest score gets build first. Alpha makes a
package advance the queue faster overtaking other packages while beta
makes packages start further up in the queue.
By adjusting the changes to alpha and beta each aspect of a source can
be finely tuned to have some affect on the queue. So random developer
can influence the priority by setting the urgency but not so much as
to abuse the power and deadlock other packages.
Instead of the urgency of uploads the number of bugs (weighted by
priority) could be used instead or on top of that. Or the number of
depends, revers depends, dep-waits, .... A lot of aspects could be
added up to set alpha and beta for each package.
Even alpha=1, beta=-<current static queue position> and time in
minutes would be an improvement. That would mean that after 6 days any
package would be build before a fresh upload of the most essential
package.
MfG
Goswin
Reply to: