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