QA 'vote' at the go/no-go meetings
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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