QA 'vote' at the go/no-go meetings

James Laska jlaska at redhat.com
Wed May 18 19:58:42 UTC 2011


On Tue, 2011-05-17 at 20:09 -0700, Adam Williamson wrote:
> On Wed, 2011-05-18 at 02:04 +0000, "Jóhann B. Guðmundsson" wrote:
> > On 05/18/2011 01:16 AM, Adam Williamson wrote:
> > > to specify the basis on which QA's 'vote' at this meeting is cast. It's
> > > really entirely deterministic; there's no discretion involved. If there
> > > are open unaddressed blockers, we do not approve the candidate for
> > > release. If there are no open unaddressed blockers, we do approve the
> > > candidate for release. There's really no wiggle room in this: any reason
> > > we have to not approve the release should be phrased as a release
> > > blocking bug in any case.
> > 
> > Then I simply propose that the go-no meeting will be dropped and instead 
> > after we have confirm that there are no unaddressed blockers and we have 
> > confirmed that all release criteria have been met on a blocker review 
> > meeting then the chair holder of that meeting sends an ack from the QA 
> > to fpl leader and cc fesco and release engineering team which then will 
> > send their ack when ready and ones fpl has recived ack from all three 
> > parties he declares a release ( Alpha/Beta/GA ).
> 
> I'm open to the possibility for sure, the meeting usually winds up being
> either a straightforward rubber stamp or a dissection of why we can't
> ship, neither of which really really needs to happen. It's possibly a
> good thing to have just as a failsafe in case something really odd
> happens, I guess. But then, we also have the release readiness meeting,
> I'm not really sure we need to have a go/no-go that's separate from that
> now we have a clear release blocker process.

Historically, the two meetings served different functions.  The first
(go/no-go) was primarily focused on engineering readiness.  In recent
releases, I think this has appropriately adjusted to focus on how the
release holds up to the criteria.

The Readiness meeting (Robyn can correct me), is more of a Fedora-wide
coordination meeting to ensure each team knows it's role in the release
process.  This meeting is typically held after we have concluded the
release criteria have been met.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110518/edbfc46f/attachment.bin 


More information about the test mailing list