The "Package sets" criterion for Alpha currently reads:
"When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
This was drafted prior to Product-ization. It has a bug - you can't do that from the Server DVD, and that's intended - and two problems - it's too focused on desktops for the new Product-y world, and the 'graphical' restriction seems arbitrary (TUI should work regarding package sets too). It also is missing something: there's no requirement about what the *default* package set should be.
I propose we re-word the Alpha criterion to:
"When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set."
and add a Beta criterion:
"When installing with a release-blocking dedicated installer image, the default package set must be correct."
with an explanatory note that 'correct' means the package set intended by the group responsible for the image - Product WG, FESCo or whoever.
I'm not sure whether we need a requirement for non-default package sets. Note that the case for offline media is already covered by Alpha criterion "No broken packages":
"There must be no errors in any package on the release-blocking images which cause the package to fail to install."
network installs using updates media don't really need to block on package set issues, as they can be fixed. That leaves the question of whether we'd want to block the release if, say, there was a bug which meant that if you tried to netinst KDE without the updates repos enabled, it failed. What do folks think about that?
On Tue, 2014-12-23 at 10:21 -0800, Adam Williamson wrote:
The "Package sets" criterion for Alpha currently reads:
"When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
This was drafted prior to Product-ization. It has a bug - you can't do that from the Server DVD, and that's intended - and two problems - it's too focused on desktops for the new Product-y world, and the 'graphical' restriction seems arbitrary (TUI should work regarding package sets too). It also is missing something: there's no requirement about what the *default* package set should be.
Just for the record, this proposal was prompted by noticing the default package set for Rawhide boot.iso is wrong since the switch to dnf by default. If anyone else notices that, I've already filed the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1177002
if this proposal is accepted, that bug can be a Beta blocker.
On Tue, Dec 23, 2014 at 10:21:11AM -0800, Adam Williamson wrote:
<snip>
I propose we re-word the Alpha criterion to:
"When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set."
and add a Beta criterion:
"When installing with a release-blocking dedicated installer image, the default package set must be correct."
with an explanatory note that 'correct' means the package set intended by the group responsible for the image - Product WG, FESCo or whoever.
+1 to the rewording.
I'm not sure whether we need a requirement for non-default package sets. Note that the case for offline media is already covered by Alpha criterion "No broken packages":
"There must be no errors in any package on the release-blocking images which cause the package to fail to install."
network installs using updates media don't really need to block on package set issues, as they can be fixed. That leaves the question of whether we'd want to block the release if, say, there was a bug which meant that if you tried to netinst KDE without the updates repos enabled, it failed. What do folks think about that?
I'd be for blocking on a broken netinst (like your example), but if the repos are the same used for image creation this shouldn't really be an issue, right? (Yeah, I know I used the "S" word :p ) AIUI things would break in other places if this particular issue was to come up. Is my understanding correct?
On Tue, 2014-12-23 at 15:39 -0700, Mike Ruckman wrote:
I'd be for blocking on a broken netinst (like your example), but if the repos are the same used for image creation this shouldn't really be an issue, right? (Yeah, I know I used the "S" word :p ) AIUI things would break in other places if this particular issue was to come up. Is my understanding correct?
Not entirely, no, because the netinst can do much more than any offline install image, let alone the release-blocking ones. The release-blocking images cover the environment groups for Workstation, Server, Cloud, and the KDE desktop, pretty much. netinst can install any environment group listed in comps, with any of its optional package groups.
In practice I suspect we'd only be likely to block on the netinst not being able to install one of the env groups that corresponds to a release blocking image, and in practice that would be unlikely to happen without breaking that image, yeah (though there's probably some corner case or other, e.g. where there's a bug in a package that's part of the Workstation env group but is stripped from the live image for space reasons, or whatever).
On Tue, 2014-12-23 at 10:21 -0800, Adam Williamson wrote:
The "Package sets" criterion for Alpha currently reads:
"When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
This was drafted prior to Product-ization. It has a bug - you can't do that from the Server DVD, and that's intended - and two problems - it's too focused on desktops for the new Product-y world, and the 'graphical' restriction seems arbitrary (TUI should work regarding package sets too). It also is missing something: there's no requirement about what the *default* package set should be.
I propose we re-word the Alpha criterion to:
"When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set."
and add a Beta criterion:
"When installing with a release-blocking dedicated installer image, the default package set must be correct."
with an explanatory note that 'correct' means the package set intended by the group responsible for the image - Product WG, FESCo or whoever.
I'm not sure whether we need a requirement for non-default package sets. Note that the case for offline media is already covered by Alpha criterion "No broken packages":
"There must be no errors in any package on the release-blocking images which cause the package to fail to install."
network installs using updates media don't really need to block on package set issues, as they can be fixed. That leaves the question of whether we'd want to block the release if, say, there was a bug which meant that if you tried to netinst KDE without the updates repos enabled, it failed. What do folks think about that?
Here's a ping on this (as I only got feedback from Mike before - anyone else?) and a modification: I'd like to extend the Beta criterion to read:
"When installing with a release-blocking dedicated installer image, the default package set must be correct, and choosing a different package set must work."
with a footnote something like:
"'work' means that the package set selection mechanism itself must work; when used, the packages that form the chosen set must actually be the ones marked for installation. Package issues that render one or more selectable package sets un-installable do not constitute a violation of this criterion, though they may be violations of other criteria."
this is to cover things like https://bugzilla.redhat.com/show_bug.cgi?id=1179362 , which I noticed when filing it is a bit of a loophole in the proposed criteria.
Any more thoughts, folks? Thanks!
On Tue, Jan 20, 2015 at 12:46:34PM -0800, Adam Williamson wrote:
Here's a ping on this (as I only got feedback from Mike before - anyone else?) and a modification: I'd like to extend the Beta criterion to read:
"When installing with a release-blocking dedicated installer image, the default package set must be correct, and choosing a different package set must work."
with a footnote something like:
"'work' means that the package set selection mechanism itself must work; when used, the packages that form the chosen set must actually be the ones marked for installation. Package issues that render one or more selectable package sets un-installable do not constitute a violation of this criterion, though they may be violations of other criteria."
this is to cover things like https://bugzilla.redhat.com/show_bug.cgi?id=1179362 , which I noticed when filing it is a bit of a loophole in the proposed criteria.
Any more thoughts, folks? Thanks!
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
That addition to the proposed criteria sounds good to me. The definition of 'work' makes sense as well.
On Tue, 2015-01-20 at 12:46 -0800, Adam Williamson wrote:
On Tue, 2014-12-23 at 10:21 -0800, Adam Williamson wrote:
The "Package sets" criterion for Alpha currently reads:
"When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
This was drafted prior to Product-ization. It has a bug - you can't do that from the Server DVD, and that's intended - and two problems - it's too focused on desktops for the new Product-y world, and the 'graphical' restriction seems arbitrary (TUI should work regarding package sets too). It also is missing something: there's no requirement about what the *default* package set should be.
I propose we re-word the Alpha criterion to:
"When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set."
and add a Beta criterion:
"When installing with a release-blocking dedicated installer image, the default package set must be correct."
with an explanatory note that 'correct' means the package set intended by the group responsible for the image - Product WG, FESCo or whoever.
I'm not sure whether we need a requirement for non-default package sets. Note that the case for offline media is already covered by Alpha criterion "No broken packages":
"There must be no errors in any package on the release-blocking images which cause the package to fail to install."
network installs using updates media don't really need to block on package set issues, as they can be fixed. That leaves the question of whether we'd want to block the release if, say, there was a bug which meant that if you tried to netinst KDE without the updates repos enabled, it failed. What do folks think about that?
Here's a ping on this (as I only got feedback from Mike before - anyone else?) and a modification: I'd like to extend the Beta criterion to read:
"When installing with a release-blocking dedicated installer image, the default package set must be correct, and choosing a different package set must work."
with a footnote something like:
"'work' means that the package set selection mechanism itself must work; when used, the packages that form the chosen set must actually be the ones marked for installation. Package issues that render one or more selectable package sets un-installable do not constitute a violation of this criterion, though they may be violations of other criteria."
this is to cover things like https://bugzilla.redhat.com/show_bug.cgi?id=1179362 , which I noticed when filing it is a bit of a loophole in the proposed criteria.
Any more thoughts, folks? Thanks!
Hum, so thinking about it a bit further, I'd like to add one more thing to this proposal.
On reflection I think we *should* require install of release blocking desktops and minimal package set to work with the frozen release package set, because I can see cases where it would be important to be able to fire off an install and be 100% confident you're not going to have package set issues; people may want to use the frozen repo for that purpose, so they're sure updates won't introduce any new problems.
We also seem to be pretty much committed to still having the universal network install image, now - at least for F22.
So, to cover those goals, propose we basically move the existing Alpha criterion to Final, with a tweak to refer to the network install image and the frozen repos specifically:
When installing with the network install image with no update repositories enabled, the installer must be able to install each of the release blocking desktops, as well as the minimal package set.
On Thu, Jan 22, 2015 at 04:20:48PM -0800, Adam Williamson wrote:
Hum, so thinking about it a bit further, I'd like to add one more thing to this proposal.
On reflection I think we *should* require install of release blocking desktops and minimal package set to work with the frozen release package set, because I can see cases where it would be important to be able to fire off an install and be 100% confident you're not going to have package set issues; people may want to use the frozen repo for that purpose, so they're sure updates won't introduce any new problems.
We also seem to be pretty much committed to still having the universal network install image, now - at least for F22.
So, to cover those goals, propose we basically move the existing Alpha criterion to Final, with a tweak to refer to the network install image and the frozen repos specifically:
When installing with the network install image with no update repositories enabled, the installer must be able to install each of the release blocking desktops, as well as the minimal package set. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
Just to sum it up for people, the proposal overall is:
- Reword the alpha criterion [0] - add a Beta criterion (with the latest extension) [1] - add a net-install Final criterion [2]
I don't see anything worrisome about any of these changes. Gives us good, well defined areas we know we want covered.
--
[0] "When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set."
[1] "When installing with a release-blocking dedicated installer image, the default package set must be correct, and choosing a different package set must work."
[2] "When installing with the network install image with no update repositories enabled, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
On 01/23/2015 11:25 AM, Mike Ruckman wrote:
On Thu, Jan 22, 2015 at 04:20:48PM -0800, Adam Williamson wrote:
Hum, so thinking about it a bit further, I'd like to add one more thing to this proposal.
On reflection I think we *should* require install of release blocking desktops and minimal package set to work with the frozen release package set, because I can see cases where it would be important to be able to fire off an install and be 100% confident you're not going to have package set issues; people may want to use the frozen repo for that purpose, so they're sure updates won't introduce any new problems.
We also seem to be pretty much committed to still having the universal network install image, now - at least for F22.
So, to cover those goals, propose we basically move the existing Alpha criterion to Final, with a tweak to refer to the network install image and the frozen repos specifically:
When installing with the network install image with no update repositories enabled, the installer must be able to install each of the release blocking desktops, as well as the minimal package set. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
Just to sum it up for people, the proposal overall is:
- Reword the alpha criterion [0]
- add a Beta criterion (with the latest extension) [1]
- add a net-install Final criterion [2]
I don't see anything worrisome about any of these changes. Gives us good, well defined areas we know we want covered.
--
[0] "When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set."
[1] "When installing with a release-blocking dedicated installer image, the default package set must be correct, and choosing a different package set must work."
[2] "When installing with the network install image with no update repositories enabled, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
+1 for the proposal, and thank you Mike for summing it up so well.
On Fri, 2015-01-23 at 09:25 -0700, Mike Ruckman wrote:
Just to sum it up for people, the proposal overall is:
- Reword the alpha criterion [0]
- add a Beta criterion (with the latest extension) [1]
- add a net-install Final criterion [2]
I don't see anything worrisome about any of these changes. Gives us good, well defined areas we know we want covered.
So, sigh, we're apparently getting flavor network install images again for F22, along with a generic network install image. So let me refine this *again*:
Alpha: "When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set." (no change)
Beta 1: "When installing with a dedicated installer image for a specific Fedora flavor, the default package set must be the correct set for that flavor."
Beta 2: "When installing with the generic network install image, selecting a package set other than the default must work."
Final: "When installing with the generic network install image with no update repositories enabled, the installer must be able to install each of the release-blocking desktops, as well as the minimal package set."
that commits us to a moderate amount of testing, and if we're worried about that we could for e.g. consider limiting the 'guarantee' for the generic netinst image to just minimal.
Thoughts? Hope I don't have to revise this any further :)
(note: the flavor netinsts may offer package set selection and be able to install other package sets - in fact, they probably will - but the idea is we only "support" them for installing their 'own' package sets.)
On Tue, 2015-01-27 at 13:52 -0800, Adam Williamson wrote:
On Fri, 2015-01-23 at 09:25 -0700, Mike Ruckman wrote:
Just to sum it up for people, the proposal overall is:
- Reword the alpha criterion [0]
- add a Beta criterion (with the latest extension) [1]
- add a net-install Final criterion [2]
I don't see anything worrisome about any of these changes. Gives us good, well defined areas we know we want covered.
So, sigh, we're apparently getting flavor network install images again for F22, along with a generic network install image. So let me refine this *again*:
Alpha: "When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set." (no change)
Beta 1: "When installing with a dedicated installer image for a specific Fedora flavor, the default package set must be the correct set for that flavor."
Beta 2: "When installing with the generic network install image, selecting a package set other than the default must work."
Final: "When installing with the generic network install image with no update repositories enabled, the installer must be able to install each of the release-blocking desktops, as well as the minimal package set."
that commits us to a moderate amount of testing, and if we're worried about that we could for e.g. consider limiting the 'guarantee' for the generic netinst image to just minimal.
Thoughts? Hope I don't have to revise this any further :)
Hum, let me try one more change: if we have official Flavor netinsts, we don't really need to *require* the generic one to work for the flavors. KDE is kind of a question, but I think to try and reduce the workload maybe we should just require the generic netinst to work for minimal. So replace the Final proposal above with:
Final: "When installing with the generic network install image with no update repositories enabled, the installer must be able to install the minimal package set."
On Thu, 2015-01-29 at 15:52 -0800, Adam Williamson wrote:
Hum, let me try one more change: if we have official Flavor netinsts, we don't really need to *require* the generic one to work for the flavors. KDE is kind of a question, but I think to try and reduce the workload maybe we should just require the generic netinst to work for minimal. So replace the Final proposal above with:
Final: "When installing with the generic network install image with no update repositories enabled, the installer must be able to install the minimal package set."
So I went ahead and implemented the final final version of this just to get it out of the way. All three criteria pages were edited:
https://fedoraproject.org/w/index.php?title=Fedora_22_Final_Release_Criteria... https://fedoraproject.org/w/index.php?title=Fedora_22_Beta_Release_Criteria&... https://fedoraproject.org/w/index.php?title=Fedora_22_Alpha_Release_Criteria...
I tweaked the default-boot-and-install test case slightly to require the default package set to be correct (enforcing that bit of the criteria):
https://fedoraproject.org/w/index.php?title=QA:Testcase_Boot_default_install...
and I added https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Inst...) to the Installation matrix to cover the 'package set selection must work' and 'minimal install from generic netinst must work' criteria:
https://fedoraproject.org/w/index.php?title=Template:Installation_test_matri...
I think that ought to cover everything. I threw the KDE package set test in as an Optional for now; we could I guess check with KDE SIG and see if they really want to block on the KDE package set being installable from the generic netinst with the frozen release repos.
Thanks folks!
oh, while I was in the pages, I adjusted the 'default boot and install' table to add the workstation and generic network install images.
-
Adam Williamson -
Greylocks -
Mike Ruckman