-----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----- -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
