Hi, folks! I'm working through some criteria issues that came up during F23 validation.
Here's one: a few times, we hit issues on live images which would have been violations of the 'post-install' release criteria, except those are explicitly for 'installed' systems. We generally felt that the relevant 'post-install' criteria should also apply to live boots.
Here's a top-level idea for handling that:
1. Rename the 'Post-install requirements' section on each criteria page to 'Post-deployment and live requirements' 2. Add some text at the top of the section explaining the general idea: the requirements in the section apply to installed systems, 'appliance' environments like the cloud images, *and* live environments, where appropriate 3. Adjust the wording of each individual criterion in the sections, where appropriate. Just to give an example:
"Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode."
would become something like:
"Unless explicitly specified otherwise, SELinux must be enabled and in enforcing mode in live environments and after system installation."
Does this general approach sound good? If so, I'll post some drafts later in the week. Thanks!
On Tue, Jan 19, 2016 at 05:21:33PM -0800, Adam Williamson wrote:
"Unless explicitly specified otherwise, SELinux must be enabled and in enforcing mode in live environments and after system installation."
Makese sense to me.
On Tue, 19 Jan 2016 17:21:33 -0800 Adam Williamson adamwill@fedoraproject.org wrote:
Hi, folks! I'm working through some criteria issues that came up during F23 validation.
...snip...
Does this general approach sound good? If so, I'll post some drafts later in the week. Thanks!
Sounds good to me.
kevin
Sounds good
On Wed, Jan 20, 2016 at 5:12 AM, Jared K. Smith jsmith@fedoraproject.org wrote:
On Tue, Jan 19, 2016 at 8:21 PM, Adam Williamson < adamwill@fedoraproject.org> wrote:
Does this general approach sound good? If so, I'll post some drafts later in the week. Thanks!
Sounds great to me.
-- Jared Smith
-- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Hi, folks! I'm working through some criteria issues that came up during F23 validation.
Here's one: a few times, we hit issues on live images which would have been violations of the 'post-install' release criteria, except those are explicitly for 'installed' systems. We generally felt that the relevant 'post-install' criteria should also apply to live boots.
Here's a top-level idea for handling that:
- Rename the 'Post-install requirements' section on each criteria page
to 'Post-deployment and live requirements' 2. Add some text at the top of the section explaining the general idea: the requirements in the section apply to installed systems, 'appliance' environments like the cloud images, *and* live environments, where appropriate 3. Adjust the wording of each individual criterion in the sections, where appropriate. Just to give an example:
"Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode."
would become something like:
"Unless explicitly specified otherwise, SELinux must be enabled and in enforcing mode in live environments and after system installation."
Does this general approach sound good? If so, I'll post some drafts later in the week. Thanks!
+1
But in the SELinux case, I think anaconda disables SELinux even on Live, so it might need some clarification.
On Wed, 2016-01-20 at 03:53 -0500, Kamil Paral wrote:
Hi, folks! I'm working through some criteria issues that came up during F23 validation.
Here's one: a few times, we hit issues on live images which would have been violations of the 'post-install' release criteria, except those are explicitly for 'installed' systems. We generally felt that the relevant 'post-install' criteria should also apply to live boots.
Here's a top-level idea for handling that:
- Rename the 'Post-install requirements' section on each criteria page
to 'Post-deployment and live requirements' 2. Add some text at the top of the section explaining the general idea: the requirements in the section apply to installed systems, 'appliance' environments like the cloud images, *and* live environments, where appropriate 3. Adjust the wording of each individual criterion in the sections, where appropriate. Just to give an example:
"Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode."
would become something like:
"Unless explicitly specified otherwise, SELinux must be enabled and in enforcing mode in live environments and after system installation."
Does this general approach sound good? If so, I'll post some drafts later in the week. Thanks!
+1
But in the SELinux case, I think anaconda disables SELinux even on Live, so it might need some clarification.
It does, but I'm not sure that's worth mentioning in the criterion, and really I was just trying to give a sample of the wording changes that would happen, not be super precise. If we're gonna mention that I'd do it in a footnote. (It only sets Permissive mode while it's actually running, it restores Enforcing on quit, IIRC).
On Tue, 2016-01-19 at 17:21 -0800, Adam Williamson wrote:
Hi, folks! I'm working through some criteria issues that came up during F23 validation.
Here's one: a few times, we hit issues on live images which would have been violations of the 'post-install' release criteria, except those are explicitly for 'installed' systems. We generally felt that the relevant 'post-install' criteria should also apply to live boots.
Here's a top-level idea for handling that:
- Rename the 'Post-install requirements' section on each criteria page
to 'Post-deployment and live requirements' 2. Add some text at the top of the section explaining the general idea: the requirements in the section apply to installed systems, 'appliance' environments like the cloud images, *and* live environments, where appropriate 3. Adjust the wording of each individual criterion in the sections, where appropriate. Just to give an example:
"Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode."
would become something like:
"Unless explicitly specified otherwise, SELinux must be enabled and in enforcing mode in live environments and after system installation."
Does this general approach sound good? If so, I'll post some drafts later in the week. Thanks!
Since people seemed to be on board with this approach, I've done the drafts. Here they are:
https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_Criteria_Postinstal... https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_Postinstall https://fedoraproject.org/wiki/User:Adamwill/Draft_Final_Criteria_Postinstal...
You can see the diff to the current criteria in the page history (I first saved an exact copy of the current criteria, then made the changes). Any thoughts on the specific changes are welcome! Thanks.
Since people seemed to be on board with this approach, I've done the drafts. Here they are:
https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_Criteria_Postinstal... https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_Postinstall https://fedoraproject.org/wiki/User:Adamwill/Draft_Final_Criteria_Postinstal...
You can see the diff to the current criteria in the page history (I first saved an exact copy of the current criteria, then made the changes). Any thoughts on the specific changes are welcome! Thanks.
Thanks for the drafts.
I hesitate whether we should mandate working updates in live environment: https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_Criteria_Postinstal...
Installing anything else than just a few small packages usually doesn't work at all, because you run out of allocated disk overlay memory (which seems to happen very soon even for systems with large amounts of physical RAM). The question is whether we want this to work "in a reasonable degree" (small updates), or whether we don't want to require it on Live at all.
I'm not completely happy about the wording of: " This criterion does apply to live environments. However, a stricter standard of judgement may be applied to conditional violations in live environments, as clean shutdown and log out functionality is relatively less important on a live boot than an installed system. " https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_Postinstall...
For example logout is necessary if you want to switch languages (and our l10n test days rely on that). Reboot and shutdown is necessary for automating stuff. I'd use the same measure as in post-install here.
On Fri, 2016-01-29 at 08:46 -0500, Kamil Paral wrote:
Since people seemed to be on board with this approach, I've done the drafts. Here they are:
https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_Criteria_Postinstal... https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_Postinstall https://fedoraproject.org/wiki/User:Adamwill/Draft_Final_Criteria_Postinstal...
You can see the diff to the current criteria in the page history (I first saved an exact copy of the current criteria, then made the changes). Any thoughts on the specific changes are welcome! Thanks.
Thanks for the drafts.
I hesitate whether we should mandate working updates in live environment: https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_Criteria_Postinstal...
Er, we wouldn't? That criterion still explicitly states "The installed system". When a criterion had text like that I didn't think it necessary to *also* add some text saying "doesn't apply to live environments", since that's just two ways of saying the same thing.
Installing anything else than just a few small packages usually doesn't work at all, because you run out of allocated disk overlay memory (which seems to happen very soon even for systems with large amounts of physical RAM). The question is whether we want this to work "in a reasonable degree" (small updates), or whether we don't want to require it on Live at all.
Yes, it was entirely my intent that this one not apply to live systems.
I'm not completely happy about the wording of: " This criterion does apply to live environments. However, a stricter standard of judgement may be applied to conditional violations in live environments, as clean shutdown and log out functionality is relatively less important on a live boot than an installed system. " https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_Post install#Shutdown.2C_reboot.2C_logout
For example logout is necessary if you want to switch languages (and our l10n test days rely on that). Reboot and shutdown is necessary for automating stuff. I'd use the same measure as in post-install here.
Hmm, IIRC this was one case that *really happened*, and I was trying to catch the flavor of our IRC discussion at the time - my memory is that we were willing to accept such bugs as blockers, but we'd maybe be more likely to waive them for only affecting a small amount of users or being workaroundable or something like that. I can go back and check the logs again, though. What do other folks think?
Thanks for checking the drafts!
2016-01-29 20:44 GMT+02:00 Adam Williamson adamwill@fedoraproject.org:
On Fri, 2016-01-29 at 08:46 -0500, Kamil Paral wrote:
I'm not completely happy about the wording of: " This criterion does apply to live environments. However, a stricter standard of judgement may be applied to conditional violations in live environments, as clean shutdown and log out functionality is relatively less important on a live boot than an installed system. " https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_Post install#Shutdown.2C_reboot.2C_logout
For example logout is necessary if you want to switch languages (and our l10n test days rely on that). Reboot and shutdown is necessary for automating stuff. I'd use the same measure as in post-install here.
Hmm, IIRC this was one case that *really happened*, and I was trying to catch the flavor of our IRC discussion at the time - my memory is that we were willing to accept such bugs as blockers, but we'd maybe be more likely to waive them for only affecting a small amount of users or being workaroundable or something like that. I can go back and check the logs again, though. What do other folks think?
The Gnome logout hang/delay bug in Fedora 23 prevented changing the language in live images for me: I asked Adam about proposing it for a blogger. I never proposed it as a blocker as the issue got accepted under more straightforward criteria soon after.
I would rather have an explicit criteria for language change for beta if there is need to have working mechanism to change language before final release.
I hesitate whether we should mandate working updates in live environment: https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_Criteria_Postinstal...
Er, we wouldn't? That criterion still explicitly states "The installed system". When a criterion had text like that I didn't think it necessary to *also* add some text saying "doesn't apply to live environments", since that's just two ways of saying the same thing.
Sorry, I missed that. You're right.
I'm not completely happy about the wording of: " This criterion does apply to live environments. However, a stricter standard of judgement may be applied to conditional violations in live environments, as clean shutdown and log out functionality is relatively less important on a live boot than an installed system. " https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_Post install#Shutdown.2C_reboot.2C_logout
For example logout is necessary if you want to switch languages (and our l10n test days rely on that). Reboot and shutdown is necessary for automating stuff. I'd use the same measure as in post-install here.
Hmm, IIRC this was one case that *really happened*, and I was trying to catch the flavor of our IRC discussion at the time - my memory is that we were willing to accept such bugs as blockers, but we'd maybe be more likely to waive them for only affecting a small amount of users or being workaroundable or something like that.
If the explanation sounds like this, I'm actually very OK with that :) I'd probably avoid saying "less important", because then it sounds like an advice to waive everything. I think it's equally important, it just has different use cases. Maybe we could say something like "a slightly different standard of judgement may be applied to conditional violations in live environments, as the use cases of live systems and installed systems are not the same". For example, if shutdown didn't work properly and on some systems actually caused restart, that could be seen as a lesser problem on Lives.
On Mon, 2016-02-29 at 05:28 -0500, Kamil Paral wrote:
For example logout is necessary if you want to switch languages (and our l10n test days rely on that). Reboot and shutdown is necessary for automating stuff. I'd use the same measure as in post-install here.
Hmm, IIRC this was one case that *really happened*, and I was trying to catch the flavor of our IRC discussion at the time - my memory is that we were willing to accept such bugs as blockers, but we'd maybe be more likely to waive them for only affecting a small amount of users or being workaroundable or something like that.
If the explanation sounds like this, I'm actually very OK with that :) I'd probably avoid saying "less important", because then it sounds like an advice to waive everything. I think it's equally important, it just has different use cases. Maybe we could say something like "a slightly different standard of judgement may be applied to conditional violations in live environments, as the use cases of live systems and installed systems are not the same". For example, if shutdown didn't work properly and on some systems actually caused restart, that could be seen as a lesser problem on Lives.
OK, I've added another sentence to the footnote to try and clarify this some more. Good to go now?
Hmm, IIRC this was one case that *really happened*, and I was trying to catch the flavor of our IRC discussion at the time - my memory is that we were willing to accept such bugs as blockers, but we'd maybe be more likely to waive them for only affecting a small amount of users or being workaroundable or something like that.
If the explanation sounds like this, I'm actually very OK with that :) I'd probably avoid saying "less important", because then it sounds like an advice to waive everything. I think it's equally important, it just has different use cases. Maybe we could say something like "a slightly different standard of judgement may be applied to conditional violations in live environments, as the use cases of live systems and installed systems are not the same". For example, if shutdown didn't work properly and on some systems actually caused restart, that could be seen as a lesser problem on Lives.
OK, I've added another sentence to the footnote to try and clarify this some more. Good to go now?
Thanks, good to go.
-
Adam Williamson -
Jared K. Smith -
Kamil Paral -
Kari Koskinen -
Kevin Fenzi -
Matthew Miller -
moshe nahmias