I'll try to revive a discussion related to ticket #567 [1] and a previous test list thread [2] (I decided to start a new one to make the subject clearer and avoid the confusion from the initial email).
During F29 development, we couldn't agree which repos should be enabled by default in anaconda *for installation* (that doesn't affect repos enabled in the installed system), and whether it changed since previous releases or not. Either way, anaconda team asked us to provide our opinion on this. We need to say which repos we'd like to install from during the Branched cycle. Note: There are no stable updates during the Branched cycle, just main repo and updates-testing. Stable updates repo is empty.
The possible options are:
a) use testing updates repo during the whole cycle up until Final RC1 (which would disable testing updates)
This has the upside of easily detecting a broken package (preventing installation or first boot) entering testing updates. However, if that happens, you can't run the installation in its default configuration, which makes things awkward especially towards the end of the cycle (that exactly caused all this discussion [3]). With this approach, you also have a fully-updated system right after installation as long as fedora repos default to updates-testing enabled (around Beta), but have extra unwanted testing updates once fedora repos default to updates-testing disabled (between Beta and Final).
b) don't use testing updates at all during the whole cycle
This makes the install process more stable (testing updates can't break it). The installed packages more closely match what the composes consist of (the composes never use testing updates, but occasionally they might include a few extra packages on top of what is currently stable, if QA requests it). After Beta, you will not end up with a system that contains testing packages, but the testing repo is disabled (that might throw some people off, if they don't know they should use dnf distrosync instead of dnf update). The downside is that before Beta, you'll need to install the system and then also update it, to have all the latest packages (including testing updates).
c) make anaconda use the same set of installation repos as are currently enabled by default in fedora-repos
This is a combination of the above. Anaconda would try to mirror the default repos also for installation. Depending on the implementation, the default repos can be either baked in during compose time (so if the particular compose was created when updates-testing was enabled by default, it would always use updates-testing, even when installing at a much later date), or it could decide dynamically at runtime (but that I assume would be much more difficult to code, and I don't expect anaconda devs to be happy about this). Both implementations can be seen as problematic in a way.
My personal opinion is that I can see very little value in having updates-testing enabled during installation. The improved stability and reliable behavior (always the same approach, installed systems always in a correct state) win it for me here. That means I'm very much in favor of option b).
There are other changes that can be discussed to improve the experience for specifically QA. For example we could ask anaconda devs to include an updates-testing repo option in the Installation Source spoke that could be used to easily enable updates-testing during installation, but that would disappear in Final RC composes. But those are slight life improvements which shouldn't really affect the major decision above, I think, and we can talk about them afterwards.
Thoughts?
[1] https://pagure.io/fedora-qa/issue/567 [2] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/t... [3] https://bugzilla.redhat.com/show_bug.cgi?id=1642089
On 11/22/18 10:59 AM, Kamil Paral wrote:
I'll try to revive a discussion related to ticket #567 [1] and a previous test list thread [2] (I decided to start a new one to make the subject clearer and avoid the confusion from the initial email).
During F29 development, we couldn't agree which repos should be enabled by default in anaconda *for installation* (that doesn't affect repos enabled in the installed system), and whether it changed since previous releases or not. Either way, anaconda team asked us to provide our opinion on this. We need to say which repos we'd like to install from during the Branched cycle. Note: There are no stable updates during the Branched cycle, just main repo and updates-testing. Stable updates repo is empty.
The possible options are:
a) use testing updates repo during the whole cycle up until Final RC1 (which would disable testing updates)
This has the upside of easily detecting a broken package (preventing installation or first boot) entering testing updates. However, if that happens, you can't run the installation in its default configuration, which makes things awkward especially towards the end of the cycle (that exactly caused all this discussion [3]). With this approach, you also have a fully-updated system right after installation as long as fedora repos default to updates-testing enabled (around Beta), but have extra unwanted testing updates once fedora repos default to updates-testing disabled (between Beta and Final).
b) don't use testing updates at all during the whole cycle
This makes the install process more stable (testing updates can't break it). The installed packages more closely match what the composes consist of (the composes never use testing updates, but occasionally they might include a few extra packages on top of what is currently stable, if QA requests it). After Beta, you will not end up with a system that contains testing packages, but the testing repo is disabled (that might throw some people off, if they don't know they should use dnf distrosync instead of dnf update). The downside is that before Beta, you'll need to install the system and then also update it, to have all the latest packages (including testing updates).
c) make anaconda use the same set of installation repos as are currently enabled by default in fedora-repos
This is a combination of the above. Anaconda would try to mirror the default repos also for installation. Depending on the implementation, the default repos can be either baked in during compose time (so if the particular compose was created when updates-testing was enabled by default, it would always use updates-testing, even when installing at a much later date), or it could decide dynamically at runtime (but that I assume would be much more difficult to code, and I don't expect anaconda devs to be happy about this). Both implementations can be seen as problematic in a way.
My personal opinion is that I can see very little value in having updates-testing enabled during installation. The improved stability and reliable behavior (always the same approach, installed systems always in a correct state) win it for me here. That means I'm very much in favor of option b).
There are other changes that can be discussed to improve the experience for specifically QA. For example we could ask anaconda devs to include an updates-testing repo option in the Installation Source spoke that could be used to easily enable updates-testing during installation, but that would disappear in Final RC composes. But those are slight life improvements which shouldn't really affect the major decision above, I think, and we can talk about them afterwards.
Thoughts?
[1] https://pagure.io/fedora-qa/issue/567 [2] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/t... [3] https://bugzilla.redhat.com/show_bug.cgi?id=1642089
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Kamil,
Thanks for your clarifications. When I'm testing a drop during the Branched, Beta and Final Release cycles, that's all I want to be testing. I load from updates-testing only when there is something that might be the source of a problem I've found and there is a newer version shown on bohdi. I never load from updates-testing en-mass. I load just one thing at a time at the command line so I know what I'm testing. I'm with you; I like option "B".
Have a Great Day!
Pat (tablepc)
On Thu, 2018-11-22 at 16:59 +0100, Kamil Paral wrote:
I'll try to revive a discussion related to ticket #567 [1] and a previous test list thread [2] (I decided to start a new one to make the subject clearer and avoid the confusion from the initial email).
During F29 development, we couldn't agree which repos should be enabled by default in anaconda *for installation* (that doesn't affect repos enabled in the installed system), and whether it changed since previous releases or not. Either way, anaconda team asked us to provide our opinion on this. We need to say which repos we'd like to install from during the Branched cycle. Note: There are no stable updates during the Branched cycle, just main repo and updates-testing. Stable updates repo is empty.
The possible options are:
a) use testing updates repo during the whole cycle up until Final RC1 (which would disable testing updates)
This has the upside of easily detecting a broken package (preventing installation or first boot) entering testing updates. However, if that happens, you can't run the installation in its default configuration, which makes things awkward especially towards the end of the cycle (that exactly caused all this discussion [3]). With this approach, you also have a fully-updated system right after installation as long as fedora repos default to updates-testing enabled (around Beta), but have extra unwanted testing updates once fedora repos default to updates-testing disabled (between Beta and Final).
b) don't use testing updates at all during the whole cycle
This makes the install process more stable (testing updates can't break it). The installed packages more closely match what the composes consist of (the composes never use testing updates, but occasionally they might include a few extra packages on top of what is currently stable, if QA requests it). After Beta, you will not end up with a system that contains testing packages, but the testing repo is disabled (that might throw some people off, if they don't know they should use dnf distrosync instead of dnf update). The downside is that before Beta, you'll need to install the system and then also update it, to have all the latest packages (including testing updates).
c) make anaconda use the same set of installation repos as are currently enabled by default in fedora-repos
This is a combination of the above. Anaconda would try to mirror the default repos also for installation. Depending on the implementation, the default repos can be either baked in during compose time (so if the particular compose was created when updates-testing was enabled by default, it would always use updates-testing, even when installing at a much later date), or it could decide dynamically at runtime (but that I assume would be much more difficult to code, and I don't expect anaconda devs to be happy about this). Both implementations can be seen as problematic in a way.
My personal opinion is that I can see very little value in having updates-testing enabled during installation. The improved stability and reliable behavior (always the same approach, installed systems always in a correct state) win it for me here. That means I'm very much in favor of option b).
There are other changes that can be discussed to improve the experience for specifically QA. For example we could ask anaconda devs to include an updates-testing repo option in the Installation Source spoke that could be used to easily enable updates-testing during installation, but that would disappear in Final RC composes. But those are slight life improvements which shouldn't really affect the major decision above, I think, and we can talk about them afterwards.
Thoughts?
Here's a bit of background:
https://bugzilla.redhat.com/show_bug.cgi?id=962522
The key point there is that if we implement your b), the checkbox would effectively do nothing in the pre-release phase at all, because there are no 'stable updates' until we freeze the release tree and do the first set of post-release updates. If you checked it, you'd get the latest 'stable' packages (for a netinst) or the packages from your DVD (for a DVD). If you un-checked it, you'd get...the same thing. As things stand now, the checkbox always does *something*, both pre- release and post-release.
I don't know if that's a good enough reason to go with a) or c) (or the behaviour before this end-of-F29 panic, which was neither), though.
AFAICS, the behaviour from before the end-of-F29 blocker dates back to at least 2013, and was basically this:
* If the box is unchecked and 'isFinal' is set, enable 'updates' * If the box is unchecked and 'isFinal' is not set, enable 'updates' and 'updates-testing' * The box is unchecked by default on netinst, checked by default on DVD
isFinal is a funny thing. For installer images, it is set at build time (using the --isfinal parameter of lorax, which writes the value into the .buildstamp file, which anaconda then reads it from), and the releng team set it to 'true' for Final candidate composes, 'false' in all other cases. For live images, it is actually determined based on the versioning of the package that provides system-release: if the 'release' of that package starts with "0.", then isFinal is set false; otherwise, isFinal is set true. So for a live image that contained fedora-release-30-0.1 , it'd be false; for a live image that contained fedora-release-30-1, it'd be true.
So the F29 panic was not really necessary, because 'final' images would have DTRT, but I can see how it happened, since this is a tricksy and obscure bit of behaviour.
I did not yet dig into how this worked before bcl did a big rewrite of this stuff in 2013.
So far as default behaviour goes, not considering UI bits, I'd be fine with b). But it *does* make the UI behaviour weird. It may be best to consider changing the UI somehow at the same time.
On Thu, Nov 22, 2018 at 6:22 PM Adam Williamson adamwill@fedoraproject.org wrote:
Here's a bit of background:
https://bugzilla.redhat.com/show_bug.cgi?id=962522
The key point there is that if we implement your b), the checkbox would effectively do nothing in the pre-release phase at all, because there are no 'stable updates' until we freeze the release tree and do the first set of post-release updates. If you checked it, you'd get the latest 'stable' packages (for a netinst) or the packages from your DVD (for a DVD). If you un-checked it, you'd get...the same thing. As things stand now, the checkbox always does *something*, both pre- release and post-release.
Internally, it should do something a bit different. If updates are enabled, the 'updates' repo would be used, even though it is empty. If updates are not used, the 'updates' repo would not be touched. So it might be possible to verify from anaconda logs that the checkbox does the right thing, even though the outcome is the same (the same package set). It's not ideal, but if we used updates+updates-testing during pre-release, it would still not be a guarantee that the checkbox will work correctly post-release, we'd still need to check the logs (and hope).
This is further complicated by the new modular repos (updates-modular, updates-testing-modular), which we should ideally check to be covered properly by the checkbox as well. The best avenue again seems to be checking the logs (and if they're not clear, ask anaconda devs to make them clearer).
(This proposal assumes that both 'updates' and 'updates-modular' and always enabled or disabled together, and the same applies to 'updates-testing' and 'updates-testing-modular').
I don't know if that's a good enough reason to go with a) or c) (or the behaviour before this end-of-F29 panic, which was neither), though.
AFAICS, the behaviour from before the end-of-F29 blocker dates back to at least 2013, and was basically this:
- If the box is unchecked and 'isFinal' is set, enable 'updates'
- If the box is unchecked and 'isFinal' is not set, enable 'updates'
and 'updates-testing'
- The box is unchecked by default on netinst, checked by default on DVD
isFinal is a funny thing. For installer images, it is set at build time (using the --isfinal parameter of lorax, which writes the value into the .buildstamp file, which anaconda then reads it from), and the releng team set it to 'true' for Final candidate composes, 'false' in all other cases. For live images, it is actually determined based on the versioning of the package that provides system-release: if the 'release' of that package starts with "0.", then isFinal is set false; otherwise, isFinal is set true. So for a live image that contained fedora-release-30-0.1 , it'd be false; for a live image that contained fedora-release-30-1, it'd be true.
Thanks for a summary. We figured most of that eventually during F29 release, but it was quite a challenge to discover that :/
So the F29 panic was not really necessary, because 'final' images would have DTRT, but I can see how it happened, since this is a tricksy and obscure bit of behaviour.
Right, it would have, and it did. But the problem, iirc, was that we couldn't verify a certain blocker to be fixed in a nightly, because updates-testing contained a broken dbus. And now that I think about it, we probably could have just toggled the updates checkbox in anaconda, but nobody realized that (and it wouldn't be a default installation, but that wouldn't have been so much of a problem, I think).
I did not yet dig into how this worked before bcl did a big rewrite of this stuff in 2013.
So far as default behaviour goes, not considering UI bits, I'd be fine with b). But it *does* make the UI behaviour weird. It may be best to consider changing the UI somehow at the same time.
Yes, some UI changes would be nice. But those would be mostly targeted at us (QA), because the current UI is mostly confusing during pre-release. So I figured we can propose some changes once we clarify what default behavior we want to see.
Do you have any specific proposals for UI?
I could imagine this: * Rephrase the current updates checkbox from "Don't install latest updates" to "Install latest updates". A negative sentence in a checkbox is a designer's no-no, because it makes all conversations and even thinking about it difficult. Mkolman from anaconda already said he would be happy to change that. * We could always think about adding "Install latest *stable* updates" word into it, to make it clear for us, but I'm not sure if it's not superfluous for the general user. * Into Additional Repositories section, add updates-testing repo item, disabled by default, and only visible in pre-release composes. Mkolman from anaconda said they definitely don't want to offer updates-testing in public releases, because some people then use it without understanding what it is, and they get all the bug reports then. And I can understand that. But perhaps they could be convinced to show it up just for us, during pre-release. That would make enabling updates-testing simple, and it would also make the checkbox behavior clear (that it's related to stable updates only).
Can you imagine anything else, or would modify some of that above?
Thanks.
On Fri, 2018-11-23 at 10:02 +0100, Kamil Paral wrote:
On Thu, Nov 22, 2018 at 6:22 PM Adam Williamson adamwill@fedoraproject.org wrote:
Here's a bit of background:
https://bugzilla.redhat.com/show_bug.cgi?id=962522
The key point there is that if we implement your b), the checkbox would effectively do nothing in the pre-release phase at all, because there are no 'stable updates' until we freeze the release tree and do the first set of post-release updates. If you checked it, you'd get the latest 'stable' packages (for a netinst) or the packages from your DVD (for a DVD). If you un-checked it, you'd get...the same thing. As things stand now, the checkbox always does *something*, both pre- release and post-release.
Internally, it should do something a bit different. If updates are enabled, the 'updates' repo would be used, even though it is empty. If updates are not used, the 'updates' repo would not be touched. So it might be possible to verify from anaconda logs that the checkbox does the right thing, even though the outcome is the same (the same package set). It's not ideal, but if we used updates+updates-testing during pre-release, it would still not be a guarantee that the checkbox will work correctly post-release, we'd still need to check the logs (and hope).
This is further complicated by the new modular repos (updates-modular, updates-testing-modular), which we should ideally check to be covered properly by the checkbox as well. The best avenue again seems to be checking the logs (and if they're not clear, ask anaconda devs to make them clearer).
Looking at the code, I don't think they are covered, so that'd be something to file a bug or PR on. :) The code is in pyanaconda/payload/dnfpayload.py , in setUpdatesEnabled().
Yes, some UI changes would be nice. But those would be mostly targeted at us (QA), because the current UI is mostly confusing during pre-release.
Sure, other people *do* use pre-releases though :P
So I figured we can propose some changes once we clarify what default behavior we want to see.
Do you have any specific proposals for UI?
I could imagine this:
- Rephrase the current updates checkbox from "Don't install latest updates"
to "Install latest updates". A negative sentence in a checkbox is a designer's no-no, because it makes all conversations and even thinking about it difficult. Mkolman from anaconda already said he would be happy to change that.
Yeah, it sure made writing the explanation weird...
- We could always think about adding "Install latest *stable* updates" word
into it, to make it clear for us, but I'm not sure if it's not superfluous for the general user.
I think it is, a bit. I don't think it really helps a lot with the pre- release case either, as it doesn't address the fundamental weirdness that the checkbox simply doesn't change the resulting package set at all in that case. It still suggests that it will do *something* merely by virtue of, well, being there.
- Into Additional Repositories section, add updates-testing repo item,
disabled by default, and only visible in pre-release composes. Mkolman from anaconda said they definitely don't want to offer updates-testing in public releases, because some people then use it without understanding what it is, and they get all the bug reports then. And I can understand that. But perhaps they could be convinced to show it up just for us, during pre-release. That would make enabling updates-testing simple, and it would also make the checkbox behavior clear (that it's related to stable updates only).
I'm not really a huge fan of this one, it seems like it'd be a moderate amount of implementation work for a fairly small gain.
Can you imagine anything else, or would modify some of that above?
An option that's easy but I also don't really like a lot would be to just hide the checkbox for pre-releases (assuming we went with b)), i.e. don't display it if isFinal is false.
I guess another fairly easy option is just to display some additional explanatory text when isFinal is false: a note explaining that the box only enables the stable updates repos, which will probably not make any difference, and that if the tester wants to enable updates-testing they should do it using the additional repos box or whatever.
On Fri, Nov 23, 2018 at 5:47 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2018-11-23 at 10:02 +0100, Kamil Paral wrote:
On Thu, Nov 22, 2018 at 6:22 PM Adam Williamson <
adamwill@fedoraproject.org>
wrote:
Here's a bit of background:
https://bugzilla.redhat.com/show_bug.cgi?id=962522
The key point there is that if we implement your b), the checkbox would effectively do nothing in the pre-release phase at all, because there are no 'stable updates' until we freeze the release tree and do the first set of post-release updates. If you checked it, you'd get the latest 'stable' packages (for a netinst) or the packages from your DVD (for a DVD). If you un-checked it, you'd get...the same thing. As things stand now, the checkbox always does *something*, both pre- release and post-release.
Internally, it should do something a bit different. If updates are
enabled,
the 'updates' repo would be used, even though it is empty. If updates are not used, the 'updates' repo would not be touched. So it might be
possible
to verify from anaconda logs that the checkbox does the right thing, even though the outcome is the same (the same package set). It's not ideal,
but
if we used updates+updates-testing during pre-release, it would still not be a guarantee that the checkbox will work correctly post-release, we'd still need to check the logs (and hope).
This is further complicated by the new modular repos (updates-modular, updates-testing-modular), which we should ideally check to be covered properly by the checkbox as well. The best avenue again seems to be checking the logs (and if they're not clear, ask anaconda devs to make
them
clearer).
Looking at the code, I don't think they are covered, so that'd be something to file a bug or PR on. :) The code is in pyanaconda/payload/dnfpayload.py , in setUpdatesEnabled().
Yes, I know. I plan to file several tickets once we agree what we want.
Yes, some UI changes would be nice. But those would be mostly targeted at us (QA), because the current UI is mostly confusing during pre-release.
Sure, other people *do* use pre-releases though :P
So I figured we can propose some changes once we clarify what default
behavior
we want to see.
Do you have any specific proposals for UI?
I could imagine this:
- Rephrase the current updates checkbox from "Don't install latest
updates"
to "Install latest updates". A negative sentence in a checkbox is a designer's no-no, because it makes all conversations and even thinking about it difficult. Mkolman from anaconda already said he would be happy
to
change that.
Yeah, it sure made writing the explanation weird...
- We could always think about adding "Install latest *stable* updates"
word
into it, to make it clear for us, but I'm not sure if it's not
superfluous
for the general user.
I think it is, a bit. I don't think it really helps a lot with the pre- release case either, as it doesn't address the fundamental weirdness that the checkbox simply doesn't change the resulting package set at all in that case. It still suggests that it will do *something* merely by virtue of, well, being there.
- Into Additional Repositories section, add updates-testing repo item,
disabled by default, and only visible in pre-release composes. Mkolman
from
anaconda said they definitely don't want to offer updates-testing in
public
releases, because some people then use it without understanding what it
is,
and they get all the bug reports then. And I can understand that. But perhaps they could be convinced to show it up just for us, during pre-release. That would make enabling updates-testing simple, and it
would
also make the checkbox behavior clear (that it's related to stable
updates
only).
I'm not really a huge fan of this one, it seems like it'd be a moderate amount of implementation work for a fairly small gain.
It depends whether there are some use cases for performing an installation with updates-testing enabled. For example testing a fixed package that previous broke installation/system boot? If we disable updates-testing for installation by default, there's no *easy* way to re-enable it, outside of a kickstart or spending a lot of effort by defining an additional repo in the GUI.
Can you imagine anything else, or would modify some of that above?
An option that's easy but I also don't really like a lot would be to just hide the checkbox for pre-releases (assuming we went with b)), i.e. don't display it if isFinal is false.
I guess another fairly easy option is just to display some additional explanatory text when isFinal is false: a note explaining that the box only enables the stable updates repos, which will probably not make any difference, and that if the tester wants to enable updates-testing they should do it using the additional repos box or whatever.
Why is so important that pre-release testers are 100% aware that stable updates repo is empty? People familiar with our processes should know that already, if they don't - what's the harm? The wide audience testing Beta release doesn't care either, they get the same package set regardless of the checkbox status.
Or do you see a bigger problem in people expecting updates-testing being used and then not getting it? That probably wouldn't include the wide Beta audience, and the regular pre-release testers will probably get used to it quickly. And the system will of course have updates-testing enabled when installed (before Beta).
On Mon, 2018-11-26 at 15:41 +0100, Kamil Paral wrote:
- Into Additional Repositories section, add updates-testing repo item,
disabled by default, and only visible in pre-release composes. Mkolman
from
anaconda said they definitely don't want to offer updates-testing in
public
releases, because some people then use it without understanding what it
is,
and they get all the bug reports then. And I can understand that. But perhaps they could be convinced to show it up just for us, during pre-release. That would make enabling updates-testing simple, and it
would
also make the checkbox behavior clear (that it's related to stable
updates
only).
I'm not really a huge fan of this one, it seems like it'd be a moderate amount of implementation work for a fairly small gain.
It depends whether there are some use cases for performing an installation with updates-testing enabled. For example testing a fixed package that previous broke installation/system boot? If we disable updates-testing for installation by default, there's no *easy* way to re-enable it, outside of a kickstart or spending a lot of effort by defining an additional repo in the GUI.
My opinion here is just that "use a kickstart, inst.repo , or add a repo in the GUI" are not that hard and sufficient to the purpose. I wouldn't agree that it's "a lot of effort" to add the repo in the GUI, tbh. Step 1) copy the URL from the /etc/yum.repos.d/ file. Step 2)...there is no step 2...
Can you imagine anything else, or would modify some of that above?
An option that's easy but I also don't really like a lot would be to just hide the checkbox for pre-releases (assuming we went with b)), i.e. don't display it if isFinal is false.
I guess another fairly easy option is just to display some additional explanatory text when isFinal is false: a note explaining that the box only enables the stable updates repos, which will probably not make any difference, and that if the tester wants to enable updates-testing they should do it using the additional repos box or whatever.
Why is so important that pre-release testers are 100% aware that stable updates repo is empty? People familiar with our processes should know that already, if they don't - what's the harm? The wide audience testing Beta release doesn't care either, they get the same package set regardless of the checkbox status.
I don't think it's "so important", but I think it's worth a trivial fix (adding a text label conditional on isFinal is not a difficult thing to do).
On Mon, Nov 26, 2018 at 6:20 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2018-11-26 at 15:41 +0100, Kamil Paral wrote:
- Into Additional Repositories section, add updates-testing repo
item,
disabled by default, and only visible in pre-release composes.
Mkolman
from
anaconda said they definitely don't want to offer updates-testing in
public
releases, because some people then use it without understanding what
it
is,
and they get all the bug reports then. And I can understand that. But perhaps they could be convinced to show it up just for us, during pre-release. That would make enabling updates-testing simple, and it
would
also make the checkbox behavior clear (that it's related to stable
updates
only).
I'm not really a huge fan of this one, it seems like it'd be a moderate amount of implementation work for a fairly small gain.
It depends whether there are some use cases for performing an
installation
with updates-testing enabled. For example testing a fixed package that previous broke installation/system boot? If we disable updates-testing
for
installation by default, there's no *easy* way to re-enable it, outside
of
a kickstart or spending a lot of effort by defining an additional repo in the GUI.
My opinion here is just that "use a kickstart, inst.repo , or add a repo in the GUI" are not that hard and sufficient to the purpose. I wouldn't agree that it's "a lot of effort" to add the repo in the GUI, tbh. Step 1) copy the URL from the /etc/yum.repos.d/ file. Step 2)...there is no step 2...
As long as the clipboard integration is working, which sadly is often broken (at least in my experience). Then it means retyping a very long URL manually each time you want to perform an installation. The same problem applies to inst.addrepo (you can't use inst.repo for additional repos, but today I learned about inst.addrepo), you have to type it manually each time or execute it from a pxe-like environment. Kickstart is fine, but it's non-trivial to write it and understand all the commands and it depends whether you need to test a "default install process" or not.
So I still think this is quite a lot of effort (assuming some package is broken for several days and you need to perform a larger number of installations using updates-testing). But if the clipboard integration is working, it's ok. I don't know how often it works and how often it doesn't, I tend get unlucky more often than I'd like :)
PS: I think there are also some traps about naming your additional repos. If you name it "updates-testing", as many people probably might, it can easily get ignored, because it clashes with an already defined name in the system. I haven't tested it lately, but I remember there have been some issues like this in the past.
I'm not completely married to the idea of showing an extra repo item in the list just in pre-release versions (more on that later), I just considered it low enough risk and a reasonable gain. We can definitely do without it, though.
Can you imagine anything else, or would modify some of that above?
An option that's easy but I also don't really like a lot would be to just hide the checkbox for pre-releases (assuming we went with b)), i.e. don't display it if isFinal is false.
I guess another fairly easy option is just to display some additional explanatory text when isFinal is false: a note explaining that the box only enables the stable updates repos, which will probably not make any difference, and that if the tester wants to enable updates-testing they should do it using the additional repos box or whatever.
Why is so important that pre-release testers are 100% aware that stable updates repo is empty? People familiar with our processes should know
that
already, if they don't - what's the harm? The wide audience testing Beta release doesn't care either, they get the same package set regardless of the checkbox status.
I don't think it's "so important", but I think it's worth a trivial fix (adding a text label conditional on isFinal is not a difficult thing to do).
Here I have a different view of the risk involved. Anything that changes a GUI layout (e.g. showing a message under the checkbox, or omitting the checkbox completely, therefore shifting all the widgets positions) make me very nervous, because if anything breaks, we'll only find about it with Final RC, and quite possibly we can miss it completely. However, that's just my perception, I can definitely ask the devs for their opinion.
If the message used an existing infrastructure of info bars sliding up from the bottom (so toggling the checkbox would show up a bar saying "this doesn't have any effect during pre-release"), I'd be less nervous, the GUI layout wouldn't be changed and the info bars are used in many other places. However, that would only inform people who clicked the checkbox (not those who read it and kept it in its current state), and I still consider this whole problem really trivial - it's not important if the checkbox has any effect or not, as long as people end up with the right set of packages, which they will.
So, what's the conclusion? Should I: 1. Ask devs to disable updates-testing completely, at all times? 2. Ask devs whether including updates-testing repo item during pre-release is safe and a good idea? 3. Ask devs whether clarifying that updates checkbox is a no-op during pre-release is safe and a good idea?
On 11/27/18 4:47 AM, Kamil Paral wrote:
On Mon, Nov 26, 2018 at 6:20 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2018-11-26 at 15:41 +0100, Kamil Paral wrote:
- Into Additional Repositories section, add updates-testing repo
item,
disabled by default, and only visible in pre-release composes.
Mkolman
from
anaconda said they definitely don't want to offer updates-testing in
public
releases, because some people then use it without understanding what
it
is,
and they get all the bug reports then. And I can understand that. But perhaps they could be convinced to show it up just for us, during pre-release. That would make enabling updates-testing simple, and it
would
also make the checkbox behavior clear (that it's related to stable
updates
only).
I'm not really a huge fan of this one, it seems like it'd be a moderate amount of implementation work for a fairly small gain.
It depends whether there are some use cases for performing an
installation
with updates-testing enabled. For example testing a fixed package that previous broke installation/system boot? If we disable updates-testing
for
installation by default, there's no *easy* way to re-enable it, outside
of
a kickstart or spending a lot of effort by defining an additional repo in the GUI.
My opinion here is just that "use a kickstart, inst.repo , or add a repo in the GUI" are not that hard and sufficient to the purpose. I wouldn't agree that it's "a lot of effort" to add the repo in the GUI, tbh. Step 1) copy the URL from the /etc/yum.repos.d/ file. Step 2)...there is no step 2...
As long as the clipboard integration is working, which sadly is often broken (at least in my experience). Then it means retyping a very long URL manually each time you want to perform an installation. The same problem applies to inst.addrepo (you can't use inst.repo for additional repos, but today I learned about inst.addrepo), you have to type it manually each time or execute it from a pxe-like environment. Kickstart is fine, but it's non-trivial to write it and understand all the commands and it depends whether you need to test a "default install process" or not.
So I still think this is quite a lot of effort (assuming some package is broken for several days and you need to perform a larger number of installations using updates-testing). But if the clipboard integration is working, it's ok. I don't know how often it works and how often it doesn't, I tend get unlucky more often than I'd like :)
PS: I think there are also some traps about naming your additional repos. If you name it "updates-testing", as many people probably might, it can easily get ignored, because it clashes with an already defined name in the system. I haven't tested it lately, but I remember there have been some issues like this in the past.
I'm not completely married to the idea of showing an extra repo item in the list just in pre-release versions (more on that later), I just considered it low enough risk and a reasonable gain. We can definitely do without it, though.
Can you imagine anything else, or would modify some of that above?
An option that's easy but I also don't really like a lot would be to just hide the checkbox for pre-releases (assuming we went with b)), i.e. don't display it if isFinal is false.
I guess another fairly easy option is just to display some additional explanatory text when isFinal is false: a note explaining that the box only enables the stable updates repos, which will probably not make any difference, and that if the tester wants to enable updates-testing they should do it using the additional repos box or whatever.
Why is so important that pre-release testers are 100% aware that stable updates repo is empty? People familiar with our processes should know
that
already, if they don't - what's the harm? The wide audience testing Beta release doesn't care either, they get the same package set regardless of the checkbox status.
I don't think it's "so important", but I think it's worth a trivial fix (adding a text label conditional on isFinal is not a difficult thing to do).
Here I have a different view of the risk involved. Anything that changes a GUI layout (e.g. showing a message under the checkbox, or omitting the checkbox completely, therefore shifting all the widgets positions) make me very nervous, because if anything breaks, we'll only find about it with Final RC, and quite possibly we can miss it completely. However, that's just my perception, I can definitely ask the devs for their opinion.
If the message used an existing infrastructure of info bars sliding up from the bottom (so toggling the checkbox would show up a bar saying "this doesn't have any effect during pre-release"), I'd be less nervous, the GUI layout wouldn't be changed and the info bars are used in many other places. However, that would only inform people who clicked the checkbox (not those who read it and kept it in its current state), and I still consider this whole problem really trivial - it's not important if the checkbox has any effect or not, as long as people end up with the right set of packages, which they will.
So, what's the conclusion? Should I:
- Ask devs to disable updates-testing completely, at all times?
- Ask devs whether including updates-testing repo item during pre-release
is safe and a good idea? 3. Ask devs whether clarifying that updates checkbox is a no-op during pre-release is safe and a good idea?
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Kamil,
My vote would be for #1; just disable updates-testing completely.
Have a Good Day!
Pat (tablepc)
On Tue, 2018-11-27 at 10:47 +0100, Kamil Paral wrote:
On Mon, Nov 26, 2018 at 6:20 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2018-11-26 at 15:41 +0100, Kamil Paral wrote:
- Into Additional Repositories section, add updates-testing repo
item,
disabled by default, and only visible in pre-release composes.
Mkolman
from
anaconda said they definitely don't want to offer updates-testing in
public
releases, because some people then use it without understanding what
it
is,
and they get all the bug reports then. And I can understand that. But perhaps they could be convinced to show it up just for us, during pre-release. That would make enabling updates-testing simple, and it
would
also make the checkbox behavior clear (that it's related to stable
updates
only).
I'm not really a huge fan of this one, it seems like it'd be a moderate amount of implementation work for a fairly small gain.
It depends whether there are some use cases for performing an
installation
with updates-testing enabled. For example testing a fixed package that previous broke installation/system boot? If we disable updates-testing
for
installation by default, there's no *easy* way to re-enable it, outside
of
a kickstart or spending a lot of effort by defining an additional repo in the GUI.
My opinion here is just that "use a kickstart, inst.repo , or add a repo in the GUI" are not that hard and sufficient to the purpose. I wouldn't agree that it's "a lot of effort" to add the repo in the GUI, tbh. Step 1) copy the URL from the /etc/yum.repos.d/ file. Step 2)...there is no step 2...
As long as the clipboard integration is working, which sadly is often broken (at least in my experience). Then it means retyping a very long URL manually each time you want to perform an installation.
Eh, I mean, it's not *that* long. I type it quite a lot. I nearly have it memorized by now. :P
The same problem applies to inst.addrepo (you can't use inst.repo for additional repos, but today I learned about inst.addrepo),
yeah, that's what I think I meant...
So I still think this is quite a lot of effort (assuming some package is broken for several days and you need to perform a larger number of installations using updates-testing). But if the clipboard integration is working, it's ok. I don't know how often it works and how often it doesn't, I tend get unlucky more often than I'd like :)
I *usually* try and get it fixed when it's not, but yeah, it does break sometimes.
PS: I think there are also some traps about naming your additional repos. If you name it "updates-testing", as many people probably might, it can easily get ignored, because it clashes with an already defined name in the system. I haven't tested it lately, but I remember there have been some issues like this in the past.
The basic idea is that you can actually just list a repo called 'updates-testing' and the pre-existing definition will be enabled and used. This is supported for kickstarts; I don't know if it works or is supported for the GUI. This is actually something we should make sure *still* works if any changes are made in this area; i.e. we should make sure that, whatever gets changed here, a kickstart with 'repo -- name=updates-testing' or whatever the syntax is still does what it's intended to...
I'm not completely married to the idea of showing an extra repo item in the list just in pre-release versions (more on that later), I just considered it low enough risk and a reasonable gain. We can definitely do without it, though.
Sure, I mean, it's ultimately just a simplicity vs. convenience trade- off. In the end I guess it'd be up to anaconda team whether it's worth the maintenance burden...
Can you imagine anything else, or would modify some of that above?
An option that's easy but I also don't really like a lot would be to just hide the checkbox for pre-releases (assuming we went with b)), i.e. don't display it if isFinal is false.
I guess another fairly easy option is just to display some additional explanatory text when isFinal is false: a note explaining that the box only enables the stable updates repos, which will probably not make any difference, and that if the tester wants to enable updates-testing they should do it using the additional repos box or whatever.
Why is so important that pre-release testers are 100% aware that stable updates repo is empty? People familiar with our processes should know
that
already, if they don't - what's the harm? The wide audience testing Beta release doesn't care either, they get the same package set regardless of the checkbox status.
I don't think it's "so important", but I think it's worth a trivial fix (adding a text label conditional on isFinal is not a difficult thing to do).
Here I have a different view of the risk involved. Anything that changes a GUI layout (e.g. showing a message under the checkbox, or omitting the checkbox completely, therefore shifting all the widgets positions) make me very nervous, because if anything breaks, we'll only find about it with Final RC, and quite possibly we can miss it completely. However, that's just my perception, I can definitely ask the devs for their opinion.
I take the point, but I think it's not a significant risk in this case as we'd be going from *more* text to *less* text, which is much less likely to cause problems. In my experience, layout bugs tend to happen when you go from *less* text to *more* text.
If the message used an existing infrastructure of info bars sliding up from the bottom (so toggling the checkbox would show up a bar saying "this doesn't have any effect during pre-release"), I'd be less nervous, the GUI layout wouldn't be changed and the info bars are used in many other places. However, that would only inform people who clicked the checkbox (not those who read it and kept it in its current state), and I still consider this whole problem really trivial - it's not important if the checkbox has any effect or not, as long as people end up with the right set of packages, which they will.
So, what's the conclusion? Should I:
- Ask devs to disable updates-testing completely, at all times?
- Ask devs whether including updates-testing repo item during pre-release
is safe and a good idea? 3. Ask devs whether clarifying that updates checkbox is a no-op during pre-release is safe and a good idea?
I think at least having it never enabled by default seems to be pretty clearly agreed-upon. Beyond that, maybe we can lay out the UI questions and ask for their opinions?
On Thu, Nov 22, 2018 at 11:00 AM Kamil Paral kparal@redhat.com wrote: ...
b) don't use testing updates at all during the whole cycle
This makes the install process more stable (testing updates can't break it). The installed packages more closely match what the composes consist of (the composes never use testing updates, but occasionally they might include a few extra packages on top of what is currently stable, if QA requests it). After Beta, you will not end up with a system that contains testing packages, but the testing repo is disabled (that might throw some people off, if they don't know they should use dnf distrosync instead of dnf update). The downside is that before Beta, you'll need to install the system and then also update it, to have all the latest packages (including testing updates).
This one has my vote, as I really feel that having install media that is unpredictably reliable (especially at Beta) reduces our ability to get people testing it.
i'm glad to see this revived.
As I mentioned before, my vote goes to B + updates-testing checkbox for prereleases.
That way we can: - test the compose as is, even installing from lives - bypass broken u-t packages
But also: - install directly with u-t in case that compose is installing but broken after install but fixed on u-t
Imho this will cover all the broken cases except when compose brokes the installation process
Stephen Gallagher <sgallagh@redhat.com erabiltzaileak hau idatzi zuen (2018 aza. 27, ar. 14:09):
On Thu, Nov 22, 2018 at 11:00 AM Kamil Paral kparal@redhat.com wrote: ...
b) don't use testing updates at all during the whole cycle
This makes the install process more stable (testing updates can't break
it). The installed packages more closely match what the composes consist of (the composes never use testing updates, but occasionally they might include a few extra packages on top of what is currently stable, if QA requests it). After Beta, you will not end up with a system that contains testing packages, but the testing repo is disabled (that might throw some people off, if they don't know they should use dnf distrosync instead of dnf update).
The downside is that before Beta, you'll need to install the system and
then also update it, to have all the latest packages (including testing updates).
This one has my vote, as I really feel that having install media that is unpredictably reliable (especially at Beta) reduces our ability to get people testing it. _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
-
Adam Williamson -
Julen Landa Alustiza -
Kamil Paral -
pmkellly＠frontier.com -
Stephen Gallagher