Re: Release update: base and standard frozen
Wouter Verhelst <wouter@grep.be> writes:
> On Mon, Aug 09, 2004 at 06:49:02AM +0200, Goswin von Brederlow wrote:
>> Matthew Palmer <mpalmer@debian.org> writes:
>>
>> > On Mon, Aug 09, 2004 at 02:04:42AM +0200, Adeodato Sim? wrote:
>> >> * Matthew Palmer [Mon, 09 Aug 2004 09:51:52 +1000]:
>> >>
>> >> > There'd hopefully be something better than that available, because
>> >> > disallowing uploads to sid just seems Wrong. I only know what it looks like
>> >> > from the developer's end, but a testing migration test that produced
>> >> > something in the excuses like "Uploaded after 2004-08-15: not a candidate
>> >> > for testing migration" or something of that sort.
>> >>
>> >> $ grep-excuses gnutls11 | grep freeze
>> >> Package is in freeze; use testing-proposed-updates for changes
>> >
>> > Well that looks interesting; I wonder what it's basis for making those
>> > decisions is, though. If it's just a list of "these packages won't be
>> > transitioned", that (a) won't really work for a whole-archive freeze, and
>> > (b) doesn't solve the problem of buildd backlog.
>>
>> Two things would be nice:
>>
>> 1. testing candidate is every package which source was uploaded X day
>> before the freeze (X being the sarge delay of the urgency). If buildds
>> take long to build a package it could enter sarge way past the freeze
>> time.
>
> While I agree in theory, there's one problem in practice:
>
> * Package gets uploaded for architecture X
> * Package doesn't get built for a week or two on architecture Y because
> of buildd backlog
> * Package is frozen (but can still migrate, because it was uploaded on
> time)
> * Package gets built on architecture Y
* Package migrates after Y uploaded the missing deb
> * There seems to be a problem on architecture Y which isn't RC, but
> which is quite an annoyance for people using the package.
>
> Now what?
What do you mean? If the package has a bug that is so anoying to make
the package unsuitable for release a new version would have to be
uploaded to t-p-u.
If the bug does not qualify for t-p-u then people have to live with
it.
Nothing new there, the only change is when frozen takes effect. I
would prefer it to take effect depending on the source upload
(predictable, maintaoners decision) and not the last binary upload of
a buildd (unpredictable, always a huge backlog before a freeze).
MfG
Goswin
Reply to: