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

Re: Release update: base and standard frozen



On Sun, Aug 08, 2004 at 02:27:30PM +0200, Ingo Juergensmann wrote:
> On Sun, Aug 08, 2004 at 01:54:48PM +0200, Wouter Verhelst wrote:
> > How about 'less uploads'? ;-)
> > Really, this is typical behaviour right before a freeze: everyone making
> > last-minute uploads to fix bugs that they want to have fixed in stable,
> > but that aren't RC. Apart from a planning, the release plan happens to
> > be a wake-up call in many cases, too. We can have overcapacity for
> > buildds, but you can't expect us to deal with every possible upload
> > spike...
> [...]
> > Yes, I realize that isn't really good enough; but this can really only
> > be handled as it should by the release managers, not by the buildd
> > admins -- although we (the m68k team, at least) are trying to do what we
> > can at our side (that is, more buildd machines are in the makes, but
> > we're 'not quite there yet'). I expect the same is happening for other
> > architectures, but I'm as knowledgeable there as any of you.
> 
> I've already asked last year for including some sort of advice (or if you
> like: "policy") into the release plan announcements to lighten the load on
> the buildds, because it's every time the same procedure: DDs uploading lots
> and lots of packages and complain loudly about the huge backlog later. 

I don't think it's going to be possible to encourage developers to upload
their packages at a slow but steady rate.  I've done it myself recently -- I
suddenly realised that there were all these little bugs, that I'd not
thought worth making a separate upload for, that would be in the stable
version if I didn't pull my finger out.  The only thing I've managed to
think up is to say "we will hard-freeze on this date" and then when that
date comes around say "Ha!  Psych!  It's actually in a week's time!".  Not
necessarily a winning strategy...

Would it be technically possible to restrain testing propagation to all
packages initially uploaded before a certain date/time?  That way testing
propagation (which requires buildd success) can take as long as it needs to
so the buildds can catch up, without having more and more packages flooding
in extending the queue.  Then we just say the "upload freeze" is at this
date, but if it takes 20 days to get everything into testing then so be it.

Perhaps this is done already.  If so, extra coolness.

- Matt



Reply to: