Re: RFS: buildbot
David Paleino wrote:
> On Tue, 24 Aug 2010 22:53:28 +0800, Paul Wise wrote:
> > Since we are now in a freeze period, splitting the package up is
> > not appropriate, nor is a new upstream version that is
> > not-preapproved by the release team.
>
> Why?
> Testing is the one frozen, not unstable.
The way I understand it: when during the freeze updates to packages
flow in the usual way (unstable -> tesing), much more testing occurs.
(IOW: t-p-u is a final resort.) The release team can also set
age-days for a particular package to a higher value than the default
implied by the urgency, precisely to enforce a longer testing period
for a change that (in their opinion) requires more testing.
If you upload to t-p-u, and sid has diverged enough compared to the
frozen testing, you are basically shooting in the dark. It means
almost zero testing, AFAICT. And it surely means you have to test
your changes in a squeeze environment; that's the minumum required.
When too much packages are uploaded to sid, the release can easilty
become unmanageable. This was evidenced by the Woody and (if I'm not
wrong, Sarge) freezes which took so long.
You're right that only testing is frozen, but unstable is the testbed
for testing. If you can't manage to keep your testbed clean and
actually using it is a "testbed", this could possibly decrease the
quality of the final bed, which is, after all, the end product
delivered to all users.
> And testing-proposed-updates is there for a specific reason, if
> needed :)
Yes, for cases when you'd really regret that you uploaded new stuff to
sid during the freeze :-) The existence of t-p-u allows you to
circumvent the *usual* testing procedure, uploading a fixed package
targeting the next stable release. Still, uploading to t-p-u is not
something you could take for granted, it still requires an explicit
ACK from the release team. IMO they're more likely to unblock a
package which was exposed to more users in sid.
> (i.e. I'm all for continuing development in sid during the freeze)
Long freezes can be frustrating, indeed, but it's best to examine a
few problematic packages and eventually fix a bug here and there, thus
shortening the freeze period. Personally, I'll try to do that (after
fixing my bugs), I think it's a better contribution than continuing
development in sid. But that's just me, everyone else can have their
own priorities, naturally.
Reply to: