Roman Zippel <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Sat, 21 Oct 2006, Anthony Towns wrote:
>
>> On Wed, Oct 18, 2006 at 06:11:38PM +0200, Geert Uytterhoeven wrote:
>> > Assumed m68k would be able to kill (most of) the backlog in time, what
>> > would
>> > prevent m68k from becoming releasable?
>> > - It didn't sustain the `95%' rate during the last x months?
>>
>> x=3, yes.
>>
>> The sustainability issue is important, because it's the best evidence we can
>> get that the arch will be supportable for ongoing security updates.
>
> Is it really the _best_ evidence? It only measures how quickly a port can
> provide security updates, but it doesn't say very much about the quality
> of them.
>
> bye, Roman
And it is not like security updates come in at the rate that sid
updates come in.
It is true that an icedove security update on m68k will takes about a
week to compile but it will compile in a week. It will not sit for 6
weeks in needs-builds and starve like some packages in sid when there
is backlog.
I don't think the 95% hurdle says much about how quickly security
updates can be build. For m68k the main influence of the % build is
the number of buildds turned on now that the toolchain bugs seem to be
fixed. The number of buildds turned on has no effect on the speed a
single package compiles though and security updates have a tight limit
on parallelity.
The avg build time per package or even better the avg build time per
security release in the past would be much better. buildd.net is
collecting avg. build time stats for what it is worth.
There could also be a SCC mechanism. Security releases could be made
without m68k for bigger packages and fixes for m68k could be announced
seperately when they finished building. If the security team agrees.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
