[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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).


Reply to: