Shouldn't we simply update the release criteria instead?

Shouldn't we simply update the release criteria instead?

That's a possibility as well, of course.

Also, I just realized I forgot to CC @adamwill and @kparal, doing so now.

Could you propose a text that could be used in the release criteria?

Basic criteria:

"The installed system must be able to download and install updates with the default console package manager." becomes "The installed system must be able to download and install appropriate updates for RPMs or any enabled/default module streams with the default console package manager."

Beta criteria:
"The installed system must be able to download and install appropriate updates for RPMs or any enabled/default module streams with the default graphical package manager in all release-blocking desktops."

@sgallagh +1 to the criteria text, though I personally would consider "be able to install updates" to imply that they are also the correct updates. Nevertheless, doesn't hurt to be more specific.

We typically draft and review release criteria on the test@ list plus any other obviously relevant lists, FWIW (though this isn't really a hard requirement written down anywhere, just a convention).

The basic idea here seems fine, I find the wording a little awkward. It also becomes arguably over specific by not considering the ostree case - I wouldn't be surprised if a release-blocking ostree image was not too far in the future. How about this?

"The installed system must be able to download and install appropriate updates with the default console tool for the relevant update type (e.g. default console package manager)."

Footnote titled "Update types":

"This includes - but is not necessarily limited to - updates for non-module packages, updates for any official module streams that are enabled (including any enabled by default in a release-blocking deployment), and rpm-ostree updates for any release-blocking rpm-ostree-based deployment. The criterion should also be reasonably interpreted to cover any other form of software distribution that we invent in future and include in an otherwise release-blocking deployment of Fedora, but have not yet updated this text to specifically refer to."

Footnote titled "'Appropriate'?":

"''Appropriate'' means that the relevant update mechanism(s) for any given deployment must apply the correct updates to the correct components, and ''not'' apply incorrect updates. To give a specific example of why this wording is included, there was previously a case where newer package versions from modules were being installed as 'updates' to systems which did not have those modules installed, only the package with the same name from the non-modular system repositories. This would be an example of 'inappropriate' updating that violated this criterion."

Footnote titled "Scope":

"This criterion applies only to Fedora-provided and controlled update mechanisms for Fedora-provided content. It should not be interpreted to cover any other 'update mechanisms' which may be included in the distribution (e.g. if an application includes a plugin system and an update mechanism for those plugins, that mechanism is not covered here)."

I realize that's a bit wordy, but the core criterion itself is simpler, with more detail in the footnotes, which is kinda the model I've been trying to use for criteria lately. I hope it also avoids as much ambiguity as possible...

Obviously, the Beta criterion would follow the same general model (in may in fact just refer to the Basic criterion's footnotes).

We typically draft and review release criteria on the test@ list plus any other obviously relevant lists

Since this discussion was already started here, I think it should remain here. But to keep people in the loop, maybe it'd suffice to send a note to test@ and devel@ with a link to this bug.

We typically draft and review release criteria on the test@ list plus any other obviously relevant lists

Since this discussion was already started here, I think it should remain here. But to keep people in the loop, maybe it'd suffice to send a note to test@ and devel@ with a link to this bug.

Yeah, that was my mistake, sorry. I probably should have gone to test@ first, but I was still thinking along the F28 lines as far as this being a FESCo blocker.

Adam: I very much like your rephrasing. Thanks for that.

This will be discussed at the 2018-05-11 FESCo meeting.

AGREED: FESCo approves adamw's proposed criterion phrasing and asks that it be included for Fedora 29 (+6, 0, -0) (sgallagh, 15:54:50)

I'll do that.

I suppose it bears mentioning that we don't currently technically require installation or removal of packages or modules to work as part of the release criteria. This is something people have expressed surprise about in the past. :) Implementing my change won't fix that - it brings modules into line with packages, but doesn't add requirements for install or remove to work for either. So if FESCo kinda wanted us to block on installing and removing modules working...that's not done yet.

There is an argument that this is 'correct' - so long as updating works, if installing doesn't work at release time, we can fix it with an update! - but it's not a very strong argument. I kinda suspect we wouldn't actually want to ship a release where installing packages or modules didn't work.

I've made the changes to the Basic and Beta criteria.