PPAs with large/many queued packages can monopolize PPA builders

[Steve Magoun]

I noticed that chromium-browser packages from the chromium-daily PPA were using all but one of the builders for each of the amd64, i386, and lpia PPAs. The chromium-browser package evidently takes ~1hr to build, so the PPA builders were effectively running at 1/4-1/3 capacity for the duration of the chromium-browser builds. When I was looking, there was a backlog of ~60 packages for each of the amd/i386/lpia PPAs. LP estimated a 3-4hr wait for packages at the end of the build queue.

It would be nice if LP had a way to detect/alleviate this situation so that a single PPA couldn't monopolize most builders for any great length of time (>15mins?).

On a related note - there are currently 3 amd64 PPA builders. When I checked, two were running chromium-browser builds and the third was building a kernel from a different PPA - so all amd64 builders were effectively blocked for everyone else. So maybe the problem is really that there needs to be way to reserve a builder for packages with a short estimated build time, to keep packages flowing through the system while other builders are building packages that take a long time (kernel, gcc, OO.o, chromium, etc).

(This was around 1830 UTC on July 2, presumably it happens every day if the chromium-daily PPA really gets updates every day)

[Steve Magoun (smagoun)]

Screenshot showing the mozilla daily PPA using all but one of the 13 i386 PPA builders (screenshot taken from https://edge.launchpad.net/builders around 3:30PM EDT on July 6).

We discovered this while looking into why a package in a public PPA hasn't started building yet, after 1+hrs in the queue.