On 11/22/18 10:59 AM, 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?
[1] https://pagure.io/fedora-qa/issue/567
[2]
https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/thread/MAAUGYLESR634VFGM2K6HE6PPOUQBYJX/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1642089
_______________________________________________
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,
Thanks for your clarifications. When I'm testing a drop during the
Branched, Beta and Final Release cycles, that's all I want to be
testing. I load from updates-testing only when there is something that
might be the source of a problem I've found and there is a newer version
shown on bohdi. I never load from updates-testing en-mass. I load just
one thing at a time at the command line so I know what I'm testing. I'm
with you; I like option "B".
Have a Great 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
