On 11 November 2013 11:56, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
I'd say the Go/No-Go should be the break point to release/not to release as
for primary offering. It could be a part of the Go/No-Go meeting to state
release readiness of all deliverables we have (based on the sign offs or
directly in the meeting?).
The slightly tricky bit is that a spin is non-blocking. Which is maybe
what's caused some of the confusion over when the deadlines are (it
sounds like "design" were testing much more regularly than we -Jam-
were and fell foul of being unsure what would count as the final
testing for a stage). I doubt anyone wants spins to be blocking, but
go/no-go works for primary offerings because if they're not in place
then 'no-go' does provide another opportunity (new RC).
What spins communities is when they need to test to get included in
the next stage. Not sure what the best answer is, arguably the Jam
TC-2 results for beta were too early on, but you can't know which TC
or RC is going to be the last one. I'm unsure if there's always a RC,
does TC ever go immediately gold? I think the options look like (in
ascending order of testing burden):
1. Require any passing TC or RC test.
2. Require any passing RC test.
3. Require the last RC to be tested.
Or, one of those options plus keeping an eye on the compose success.