On Wed, 2017-08-02 at 17:16 -0700, Adam Williamson wrote: > Hi, folks! So I've (finally) got ready an initial round of draft > changes to various wiki pages for the purpose of implementing the 'No > More Alphas' Change. You can find all the drafts in the NoMoreAlphas > category: > > https://fedoraproject.org/wiki/Category:NoMoreAlpha > > For each page I cloned the original text and saved it as the first > edit, so you can use the 'History' tab's diff feature to see the actual > changes to each page (just compare the current state to the first > edit). > > To summarize the changes, at least as I remember them, and call out > some significant choices: > > * Obviously, all Alpha-related points on the schedule template on the > Fedora Release Life Cycle page were removed. For schedule points that > were previously derived from Alpha points that got removed, I adjusted > them to derive from some other still-remaining point. > > * My proposal for 'what do we do about release criteria / validation' > is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed > 'Basic Release Criteria' (note: not versioned, I don't think it should > be), and we document that *all* composes - not just Beta and Final > candidate composes, but also Rawhide and Branched nightlies - will be > automatically tested for (and release of them gated on) compliance with > them. Which is more or less what's proposed in the Change. All external > references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is > what changed on the other criteria pages, and on the test matrix > template pages). Practically speaking, we currently have automated > testing for *most* of the existing Alpha criteria, but a few items > aren't covered. We can choose to move these to the Beta criteria, or > leave them on Basic and just accept that *actual* coverage doesn't > quite meet what we aspire to. I do *NOT* propose to have any kind of > blocker tracking bug for the Basic release criteria; it doesn't seem to > fit in the process, there is no Alpha release to block, and we can't > realistically block nightly composes on manual test results. So a > tracker bug wouldn't really have any reason to exist. In the case where > a violation of the Basic criteria makes it into composes despite the > automated testing, it should be marked as a Beta blocker. > > * There is a problem with what to do about the Change schedule: our two > sources for it don't actually agree on what the schedule *is*. The > Changes Policy page - https://fedoraproject.org/wiki/Changes/Policy - > claims that the 'Completion deadline' "falls on the same day as the > Alpha milestone freeze", but the Fedora Release Life Cycle page - > https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle - claims it > falls on the same day as the branch point, which is two weeks *before* > the Alpha freeze. Given this inconsistency I didn't really feel > confident proposing a draft for the Changes/Policy page yet; probably > it'd be good for FESCo(?) as owners of the Change process to decide > when they actually want the key dates of the Change process to be, In A > World Without Alphas. If FESCo wants to figure that out and let me > know, I can draft the changes. > > Please do look these over and provide any kind of feedback! Thanks. As there was no opposition to these changes, I have gone ahead and implemented them all, save for the changes to the Release Life Cycle page, as those conflict with some changes planned by jkurik to some extent. I'll review the status of that tomorrow and make any changes to that page that I still think should be made, without unilaterally deciding the question of how to change the release cycle. Thanks everyone! Quick notes-more-or-less-to-self: I need to do a new wikitcms release to add the Basic milestone, and the blocker bug creation script needs updating to not create Alpha blocker bugs any more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
