On 11/27/18 4:47 AM, 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.
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
Kamil,
My vote would be for #1; just disable updates-testing completely.
Have a Good Day!
Pat (tablepc)
_______________________________________________
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
