Release Team Members: input requested...

[Kate Stewart]

On Tue, 2012-04-03 at 09:46 +0200, Martin Pitt wrote:
> Kate Stewart [2012-04-02 16:54 -0500]:
> > 4/12 - Final Freeze[1] - ALL fixes should go into -proposed,  and 
> >       only copied into -release after review meeting.
> 
> This seems overly harsh to me. This is 14 days before the release, and
> we certainly want to land more bug fixes in that period. We made good
> experiences with allowing bug fixes into the release even relatively
> late (with careful review, etc.) instead of piling up many dozen 0-day
> SRUs. Requiring meetings for any fix isn't going to help much, IMHO:
> In a meeting we cannot judge well about the impact on a patch, testing
> and working with the developer who uploaded this seem a lot more
> appropriate for this. Also, forcing meetings for all of this is just
> going to slow down everyone and distract from real work.
> 
> IMHO we should continue the normal process (release team member
> reviews changes in the queue and selectively accepts) until 4/19
> (candidate window start).

I agree there are some package fixes that its pretty clear its safe,
and very limited interaction,  and don't want to slow those down, but 
have seen some system interaction ones get through that have caused 
problems on the last couple of releases. 

What's motivating this is the aim to shift our expectations back a week
so that the release candidate image really could be a releasable target.
Past releases it seemed that we've gone right up to the day before
release due to blockers being found and fixed very late, and for
scrambling to recover from things being let in to the release that
probably shouldn't have.

I was thinking of the meeting as more a identification of the person
best suited to quietly review after the meeting and make a judgment on
whether a patch was safe or not - before it gets reviewed for the next
days build.  Also,  it would be useful to make sure those that know
about factors/interactions have a chance to comment before it (which has
been ignored in the past by not reading the backscroll on IRC) and
decide if we want it in the next image build or the one after.  (ie.
staggering some of the systemic ones so they don't all land at once),
and being able to ask the testers to focus on particular areas on the
next day's builds (in advance).  

> >       All packages should be reviewed and built by 2300 GMT in
> >       -release, so they can be included in the nightly builds.
> 
> Note that we cannot make this happen for packages which just take long
> to build (Qt, LibreOffice, eglibc, etc.).

Agreed,  but we can know they'll land in the next days then, and keep
the churn/interactions down so they can be reacted to, also pre-arrange
testing on the ones of particular concern.

> > 4/19 - CandidateWindowStarts[6] - from this point forward, any of
> >       images produced could be the final one.  CRON job is disabled. 
> >       The full set of QA results needs to be gathered on these 
> >       images. Continue with daily release team meetings to agree 
> >       if any additional fixes in -proposed MUST be included,  and 
> >       let QA teams know explicitly if another round of full manual
> >       testing is going to be needed. 
> 
> I like this, especially the subtle, but important "could" -- i. e. we
> require release quality for all builds from then on, but keep the
> possibility open to pick up more fixes.

Possibility is there, but there's a high QA cost associated with it,  so
we want to make sure its needed, and batch them if we do respins to keep
the load on the testers reasonable. 

Kate