On Fri, Nov 23, 2018 at 5:47 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Fri, 2018-11-23 at 10:02 +0100, Kamil Paral wrote:
> On Thu, Nov 22, 2018 at 6:22 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>
> 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).
Looking at the code, I don't think they are covered, so that'd be
something to file a bug or PR on. :) The code is in
pyanaconda/payload/dnfpayload.py , in setUpdatesEnabled().
Yes, I know. I plan to file several tickets once we agree what we want.
> 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.
Sure, other people *do* use pre-releases though :P
> 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.
Yeah, it sure made writing the explanation weird...
> * 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.
I think it is, a bit. I don't think it really helps a lot with the pre-
release case either, as it doesn't address the fundamental weirdness
that the checkbox simply doesn't change the resulting package set at
all in that case. It still suggests that it will do *something* merely
by virtue of, well, being there.
> * 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.
Or do you see a bigger problem in people expecting updates-testing being used and then not getting it? That probably wouldn't include the wide Beta audience, and the regular pre-release testers will probably get used to it quickly. And the system will of course have updates-testing enabled when installed (before Beta).
_______________________________________________ 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
