Hi Anthony, On 2009-08-04, Anthony Towns <a...@erisian.com.au> wrote: > On Tue, Aug 04, 2009 at 01:09:14PM +0200, Philipp Kern wrote: >> I'm grateful for those suggestions, Anthony. That page is just a pain >> to maintain though. Not everything on it is up-to-date yet but I updated >> quite some chunks. > So make it easy to maintain... Attached is an example converting it to > yaml with python table generation, coping with waivers.
wow thanks, that was unexpected. I'll try to get the YAML ready soon and deploy it. > It'd be really nice to have all the buildd criteria be measurable (and then > automated). One idea might be to change "fast security" and "redundancy" into > speed/load measures, something like: > > alpha amd64 armel s390 > buildd-speed 95% 100% 50% 113% > (%ge of i386/amd64) > > buildd-load 55% 60% 95% 20% > > n-buildds 2 3 6 1 > > idle-buildds 0.9 1.2 0.3 0.8 > > where speed is calculated as the overall average of: > > time-to-build-on-$ARCH / time-to-build-on-i386/amd64 > > (ie, dpkg takes 20s to build on alpha, versus 13s to build on i386 after > and amd64+source upload would give 154%) > > load is the percentage of time on average that each buildd is actually > building something, and idle-buildds is "n-buildds * (1 - buildd-load)". > Release criteria are then something like "buildd-speed >= 50%", > "idle-buildds >= 1". This does assume though, that every buildd is doing everything which is not true for all architectures. And the buildd load is currently only calculated and stored on the buildd and not centrally. It could however be collected at some point. (We do not have all logs neither because security ones are not mailed to the log repository but only to security people.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
