On Wed, Oct 25, 2017 at 2:43 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
Hi folks!
So at the most recent blocker review meeting, we discussed the intent
of the release criteria as regards upgrades. At present we have one
criterion, at Beta:
"For each one of the release-blocking package sets, it must be possible
to successfully complete a direct upgrade from fully updated
installations of the last two stable Fedora releases with that package
set installed."
Now my *intent* in writing this was that it should cover *only* out-of-
the-box installs of the release-blocking package sets; nothing beyond
out-of-the-box functionality was supposed to be covered.
However, there seemed to be strong agreement that failure of a release-
blocking Server role to upgrade correctly should block the release.
I'm not sure if you counted my response at the meeting as "agreement", but I was simply not understanding the distinction between a default install and a post-install configured server role. (I hope I understand it properly now.)
At
least in my reading (and I wrote it!) the criterion doesn't really
cover that.
So I'm proposing changes to both make the meaning of the existing
criterion more clear, and explicitly cover the thing we agreed should
be covered.
1) Change the text of the existing criterion to read:
"For each one of the release-blocking package sets, it must be possible
to successfully complete a direct upgrade from a fully updated, clean
default installation of each of the last two stable Fedora releases
with that package set installed."
Sounds reasonable.
2) Add a new criterion to the Beta 'Server Product requirements'
section, titled "Server upgrade requirements", text:
"For each Featured Server Role, it must be possible to successfully
complete a direct upgrade from a fully updated installation of each of
the last two stable Fedora Server releases with that Server Role
deployed. The upgraded system must meet all relevant release criteria,
including criteria relating to functionality of the Server Role."
Should be decided by Server SIG, but the wording seems fine to me.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
