> > Then I added the process of tracking AcceptedPreviousRelease fixes > > and verifying that the related updates repo metalink is in shape. > > This generally looks fine, my only concern is that it's extremely > specific stuff that might go stale quite easily. But since it's not at > all an 'obvious' process, explaining it in detail is important. > > It would be nice of course if there was a tool for doing this, then the > text could be reduced to 'run the magic tool and make sure it says OK'. I'll do some thinking whether I can write such a magical tool. > > 2. Go No Go Meeting > > https://fedoraproject.org/w/index.php?title=User%3AKparal%2FDraft%3AG > > o_No_Go_Meeting&diff=436242&oldid=435628 > > > > I wanted to avoid enumerating different types of blockers and their > > conditions here, so I use the previously described fact that any open > > blocker bugs should mean No Go, otherwise it means Go. But since > > people are not machines and mistakes will happen, I used "open or > > otherwise unaddressed accepted blocker bugs" to cover the case where > > we closed some bug sooner than it should have been, and it's still > > not addressed. > > IIRC the text in fact uses "unaddressed" specifically *instead* of > saying "open", as a slight fudge for cases where a bug might still be > open but is in fact fully 'addressed'. We *are* reducing the likelihood > of that scenario with this change (i.e. we can't say "go" if a fix is > in the compose but not yet pushed stable any more), but I'm not 100% > sure we've removed any possibility of a bug being in this state > somehow. So I'm not 100% against this change but a bit worried by it. OK, so what about this? https://fedoraproject.org/w/index.php?title=User%3AKparal%2FDraft%3AGo_No_Go_Meeting&diff=436435&oldid=436434 > > > I also switched GOLD to GO, which seems to be an oversight from the > > past. > > It's not, exactly. The two terms sort of coexist, it wasn't just that > we switched from saying "gold" to saying "go" at some point. > Conceptually it's the *release candidate* specifically that gets > declared "gold", while the *release process* is "go" (or we are "go for > release") if the candidate is declared "gold". I think we could at > least *conceptually* declare a release candidate "GOLD" but not be "go" > for release. It's kinda unnecessary to have both concepts, but the text > reads slightly awkwardly if you simply do s/GOLD/GO/g/ as you did, > because we don't really "declare the release "GO"", that's a somewhat > odd phrasing. > > I don't really mind if we want to rephrase this a bit to drop the > 'gold' concept - we barely use it anywhere else but on this page - but > it feels like it should be a separate change, not part of this > revision, and it should be slightly more than just a search-n-replace > so the text doesn't read weird :) OK, I reverted this. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
