Release Team Members: input requested...

[Kate Stewart]

On Mon, 2012-04-02 at 16:12 -0700, Steve Langasek wrote:
> Hi Kate,
> 
> On Mon, Apr 02, 2012 at 04:54:43PM -0500, Kate Stewart wrote:
> > 4/12 - Final Freeze[1] - ALL fixes should go into -proposed,  and 
> >       only copied into -release after review meeting.   Full
> >       QA ISO testing run done at start, to identify problem cases.
> >       Release team meets daily for 1/2 hour at 1600 GMT in
> >       #ubuntu-release to figure out which fixes we want to 
> >       include in overnight images,  and determine who is best match 
> >       for reviewing them for risk/upside, and copy vs. rebuild into 
> >       -release.  There should be no fixes being added, unless its
> >       a fix that a member of the release team specifically  
> >       requests.  Images continue to be built daily.    All packages
> >       should be reviewed and built by 2300 GMT in -release, so they
> >       can be included in the nightly builds.
> 
> A daily review meeting seems like a lot of overhead just to have packages
> doled out for review.  Why should this be a daily meeting, as opposed to
> release team members claiming packages as they come in the queue and
> reviewing them immediately?
> 
> I can certainly see that we might need more coordination between team
> members about what's actually going in, for you to have better control over
> what's going to trigger image respins.  I just have my doubts that a meeting
> is the most effective way to accomplish that.

If you've got better suggestions on how we can keep in synch with who's
doing what reviews,  etc.  I'm definitely interested.   If we had a
queue audit,  this would be less of an issue.  But we don't have the
queue audit and people don't remember to always flag in the channel that
they were the reviewers of a package,  so there's definitely been some
wasted time,  tracking down why something was approved.  

Also there have been a couple of times where people have flagged things
NOT to approve in the channel,  but left them in the queue as SRU
targets, and someone else later came along and let them in.   Would like
to avoid seeing this happen this time around.

> 
> Also, to the point in the my mail that -proposed is unnecessary overhead in
> the case where we know it's not causing uninstallability and we know we're
> going to take the fix: if we're asking whether to copy from -proposed vs.
> rebuilding into release, that's usually a good sign we shouldn't have
> used -proposed for it in the first place.

Fair enough,  maybe we should look at it the other way,  and if things
are uploaded to -release queue,  and its clear they may cause issues,
but we might want them as SRU or opportunity targets maybe rejecting and
requesting they be uploaded to -proposed?   

Kate