Not 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?
}}}