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?

On Thu, Nov 22, 2018 at 6:22 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; 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).

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?

> > * 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.

On Mon, Nov 26, 2018 at 6:20 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; 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? _______________________________________________ test mailing list -- test(a)lists.fedoraproject.org To unsubscribe send an email to test-leave(a)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

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).