On Tue, 2018-11-27 at 10:47 +0100, Kamil Paral wrote: > On Mon, Nov 26, 2018 at 6:20 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> > 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: > 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? 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? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
