Re: Bits from the release team and request for discussion
Hi Anthony,
On 2009-08-04, Anthony Towns <aj@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
Reply to: