-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/02/2015 06:42 AM, Kamil Paral wrote:
>> Taking all of this into account, would this be a reasonable
>> idea? 1. At Go/No-Go voting time, all updates which block F-N
>> release but belong to F-M (M<N) release, must be already
>> pushed stable. If this is not the case and it's the last
>> blocking issue, selected tasks (like copying compose trees into
>> appropriate places) can be performed, and Go/No-Go will be
>> rescheduled to the day and time when it is expected that those
>> updates will have been pushed.
>
> I think thats not a great idea. It gets back to why we only slip
> in one week increments. If say we have a go/no-go on a thursday
> and the only thing blocking it is some update thats not pushed
> stable all the way yet, we reschedule for friday and if it's not
> done then we schedule for saturday? This means everyone has to
> work extra hours without even being sure when the release will
> be.
If the update is pending stable and just not pushed, it might
sense to move it one day, yes (most probably skipping weekends,
though).
Sure, this I think is sane.
If
it needs more testing, we might decide to postpone it a several
days. If it's not available at all yet, waiting an extra week might
be the right choice. So it would depend on the situation and best
guess of folks at Go/No-Go.
I think this shouldn't be conditional: if at Go/No-Go the update isn't
at least ready to hit the button, then we slip a week. Period.
"Waiting a couple days for testing" is just adding unnecessary
uncertainty.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZfG8cACgkQeiVVYja6o6ND1ACgoC5EhmSRms9vtpvoiXDjYnFo
4psAoLAWPYIwzl+KJ6waGqrlHLC0rA01
=0Xn+
-----END PGP SIGNATURE-----