On 08/03/2017 05:46 AM, Adam Williamson wrote:
* 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.
On a slightly different thought, if we run all existing Alpha criteria tests in rawhide, we can then probably look at existing Alpha blocker as Branch blocker.. i.e, we don't branch unless the blockers are fixed and thereby keeping rawhide at Alpha quality all the time. We might want to call 'Basic Release Criteria' as 'Basic Branch Criteria'.
Regards, Sudhir _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
