On Mon, 2016-02-29 at 04:42 -0500, Kamil Paral wrote: > > > > Hello folks, > > > > I'd like to return to the high-level overview for this topic and discuss the > > changes we plan to do in our SOPs. > Since there was not much feedback, we agreed on a QA meeting that > I'll just go ahead and draft all related SOP changes. Here we go: > > 1. SOP blocker bug process: > https://fedoraproject.org/w/index.php?title=User%3AKparal%2FDraft%3AS > OP_blocker_bug_process&diff=436236&oldid=435641 > > I've clarified that we should not close any blocker bug until the fix > is pushed to a stable repo *and* also part of a TC/RC (if > appropriate). If this is kept, it means we can easily look at the > list of blockers and decide whether any type of blocker is still > blocking us (some blocker bugs open) or not (all blocker bugs > closed). This will be important in other SOPs. Yeah, this looks fine. The current text wasn't even really considering the case of 'pushed stable but not included in a compose' as things usually happen the other way around (and we specifically had cases where fixes got included in a compose but not pushed stable, the bug was closed, and we never remembered to push the fix to stable). > 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'. > This document shares many templates with > https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process , > but I do not intend to modify that one, so I might need you help, > Adam, to modify the templates in such a way we adjust only one of the > documents. This shouldn't really be too difficult. The text in question is all a part of a single template, I believe: https://fedoraproject.org/wiki/Template:Blocker_freeze_exception_tracking the first change applies equally to FE bugs, so there's no problem there, just apply the change straight to the template. The second chunk is entirely inapplicable to the FE process as the concept of "non-media freeze exceptions" makes no sense and thus is not a thing; this actually makes things simple, because it means you can just dump that text straight into https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process right after the text "{{Blocker_freeze_exception_tracking|type=blocker}}". You'll notice that I added the previous chunks about non-media blockers directly to the blocker SOP page too, for the same reason: they're completely inapplicable to the FE process and always will be, so it doesn't make any sense to put them in the shared templates and conditionalize them not to appear for the blocker page, it's simpler to just put them straight into the blocker page. > 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. > 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 :) > Do the changes look OK to you? Aside from the above notes, yup! Thanks for working on this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
