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