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). (This proposal assumes that both 'updates' and 'updates-modular' and always enabled or disabled together, and the same applies to 'updates-testing' and 'updates-testing-modular'). > I don't know if that's a good enough reason to go with a) or c) (or the > behaviour before this end-of-F29 panic, which was neither), though. > > AFAICS, the behaviour from before the end-of-F29 blocker dates back to > at least 2013, and was basically this: > > * If the box is unchecked and 'isFinal' is set, enable 'updates' > * If the box is unchecked and 'isFinal' is not set, enable 'updates' > and 'updates-testing' > * The box is unchecked by default on netinst, checked by default on DVD > > isFinal is a funny thing. For installer images, it is set at build time > (using the --isfinal parameter of lorax, which writes the value into > the .buildstamp file, which anaconda then reads it from), and the > releng team set it to 'true' for Final candidate composes, 'false' in > all other cases. For live images, it is actually determined based on > the versioning of the package that provides system-release: if the > 'release' of that package starts with "0.", then isFinal is set false; > otherwise, isFinal is set true. So for a live image that contained > fedora-release-30-0.1 , it'd be false; for a live image that contained > fedora-release-30-1, it'd be true. > Thanks for a summary. We figured most of that eventually during F29 release, but it was quite a challenge to discover that :/ > > So the F29 panic was not really necessary, because 'final' images would > have DTRT, but I can see how it happened, since this is a tricksy and > obscure bit of behaviour. > Right, it would have, and it did. But the problem, iirc, was that we couldn't verify a certain blocker to be fixed in a nightly, because updates-testing contained a broken dbus. And now that I think about it, we probably could have just toggled the updates checkbox in anaconda, but nobody realized that (and it wouldn't be a default installation, but that wouldn't have been so much of a problem, I think). > > I did not yet dig into how this worked before bcl did a big rewrite of > this stuff in 2013. > > So far as default behaviour goes, not considering UI bits, I'd be fine > with b). But it *does* make the UI behaviour weird. It may be best to > consider changing the UI somehow at the same time. > 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. 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. * 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. * 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). Can you imagine anything else, or would modify some of that above? Thanks.
_______________________________________________ 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
