On Fri, Nov 23, 2018 at 5:47 PM Adam Williamson <adamw...@fedoraproject.org> wrote:
> On Fri, 2018-11-23 at 10:02 +0100, Kamil Paral wrote: > > On Thu, Nov 22, 2018 at 6:22 PM Adam Williamson < > adamw...@fedoraproject.org> > > 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. > 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. 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@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
