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