On Thu, 2018-11-22 at 16:59 +0100, Kamil Paral wrote: > I'll try to revive a discussion related to ticket #567 [1] and a previous > test list thread [2] (I decided to start a new one to make the subject > clearer and avoid the confusion from the initial email). > > During F29 development, we couldn't agree which repos should be enabled by > default in anaconda *for installation* (that doesn't affect repos enabled > in the installed system), and whether it changed since previous releases or > not. Either way, anaconda team asked us to provide our opinion on this. We > need to say which repos we'd like to install from during the Branched > cycle. > Note: There are no stable updates during the Branched cycle, just main repo > and updates-testing. Stable updates repo is empty. > > The possible options are: > > a) use testing updates repo during the whole cycle up until Final RC1 > (which would disable testing updates) > > This has the upside of easily detecting a broken package (preventing > installation or first boot) entering testing updates. However, if that > happens, you can't run the installation in its default configuration, which > makes things awkward especially towards the end of the cycle (that exactly > caused all this discussion [3]). With this approach, you also have a > fully-updated system right after installation as long as fedora repos > default to updates-testing enabled (around Beta), but have extra unwanted > testing updates once fedora repos default to updates-testing disabled > (between Beta and Final). > > b) don't use testing updates at all during the whole cycle > > This makes the install process more stable (testing updates can't break > it). The installed packages more closely match what the composes consist of > (the composes never use testing updates, but occasionally they might > include a few extra packages on top of what is currently stable, if QA > requests it). After Beta, you will not end up with a system that contains > testing packages, but the testing repo is disabled (that might throw some > people off, if they don't know they should use dnf distrosync instead of > dnf update). > The downside is that before Beta, you'll need to install the system and > then also update it, to have all the latest packages (including testing > updates). > > c) make anaconda use the same set of installation repos as are currently > enabled by default in fedora-repos > > This is a combination of the above. Anaconda would try to mirror the > default repos also for installation. Depending on the implementation, the > default repos can be either baked in during compose time (so if the > particular compose was created when updates-testing was enabled by default, > it would always use updates-testing, even when installing at a much later > date), or it could decide dynamically at runtime (but that I assume would > be much more difficult to code, and I don't expect anaconda devs to be > happy about this). Both implementations can be seen as problematic in a way. > > > My personal opinion is that I can see very little value in having > updates-testing enabled during installation. The improved stability and > reliable behavior (always the same approach, installed systems always in a > correct state) win it for me here. That means I'm very much in favor of > option b). > > > There are other changes that can be discussed to improve the experience for > specifically QA. For example we could ask anaconda devs to include an > updates-testing repo option in the Installation Source spoke that could be > used to easily enable updates-testing during installation, but that would > disappear in Final RC composes. But those are slight life improvements > which shouldn't really affect the major decision above, I think, and we can > talk about them afterwards. > > Thoughts? 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. 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. 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. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
