On Tue, 2018-11-27 at 10:47 +0100, Kamil Paral wrote:
On Mon, Nov 26, 2018 at 6:20 PM Adam Williamson
<adamwill(a)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:
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