-----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.