launchpad developmentNot many people are perfectly happy with the current build queue system. The scoring system is complex, it is easy to starve certain types of jobs, and the controls for configuring system behaviour are difficult to learn.
We would like to have a better system, one in which:
- fast jobs get done quickly
- no job gets starved
- XXX - add more here
Here are some proposed alternatives, and our thoughts on the matter.
Stochastic Fairness Queueing
See http://www.opalsoft.net/qos/DS-25.htm
If we implement something like SFQ (http://www.opalsoft.net/qos/DS-25.htm) instead, I am confident we'll get much better service times for builds people care about, and be *much* more resilient against things like archive copy builds being done without the right metadata. In a SFQ system, we can reasonably accurately and cheaply estimate the time the next build in each flow (which perhaps we map to PPA+distroseries) will be dispatched (and thus the probably completion time). Packages further back in your PPA wouldn't have a time at all (without some hairy queries) - but perhaps we could say something like: PPA/+queue Foo: dispatching in 2 hours Bar: queued Gam: queued How do you think that that would feel to a user?
