Just to clarify, the current anaconda behavior is to enable updates-testing always when it's not marked as RC (i.e. isFinal == false in buildstamp from pungi). Our impression was that anaconda honored the fedora-repos defaults in the past, i.e. updates-testing was disabled somewhere between Beta and Final, and close to the RC time even the nightlies had updates-testing disabled. Anaconda team couldn't confirm that.

The current code in anaconda is here:
https://github.com/rhinstaller/anaconda/blob/1caf765733a1cdcb58e9227047c2468725bdbf13/pyanaconda/payload/dnfpayload.py#L899
and it is called whenever the "(don't) install updates" checkbox is toggled, and also perhaps during initialization:
https://github.com/rhinstaller/anaconda/blob/1caf765733a1cdcb58e9227047c2468725bdbf13/pyanaconda/payload/dnfpayload.py#L899

@lruzicka volunteered to push this forward, many thanks.

Thanks, Kamil, for the entry data. I will think about it and explore the options a little bit. Then come back with some suggestions.

The more I think about it, the more I feel like Anaconda should never enable the -testing repos automatically. There is value in testers having access to those repos in their installed system during pre-release time, but I feel like we should be trying to keep the install process itself as stable as possible so as not to discourage testers.

Also, please note that we now also have u-t for modules which were not figured in here; in the case of the bug we just saw, only the traditional RPM u-t was enabled. Whatever else is decided, these two repos should be enabled or disabled together.

How updates-testing and updates-testing-modular should be handled in Fedora 30

Possible scenarios to treat testing repositories

• always switched off
• always switched on
• sometimes off and sometimes on
• others

Possible impact on users according to a given scenario

Always switched off

Pros

• Getting only approved updates only safer.
• System is more stable and less prone to break.
• The status of the testing is always clear.

Cons

• No testing packages in Beta could mean less testing altogether.
• If there is a bug in a stable package, it takes longer to update.

Always switched on

Pros

• Newest packages always in the system during all phases of development.
• More bug reports found to more systems using it.

Cons

• Unstable system with possible severe breakdowns.
• More bugs. Some possibly dangerous.

Sometimes off and sometimes on

Pros

• Possibility to have testing packages in certain phases.
• Possibility to have stability in certain phases.

Cons

• The switch must be maintained.
• Inability to do so can bring problems.

How to achieve those scenarios?

Always off

• No special actions needed.
• The repos will be configured with testing repos switched off.

Always on

• No special actions needed.
• The repos will be configured with testing repos switched on.

Sometimes off and sometimes on

• Need to take care of this, so the repo status should be updated post milestone.
• The repos will be configured differently in different phases.

How to configure on user level

• Using dnf. Users are able to use dnf to switch on, off repos temporarily or permanently.
• Using configuration files. Users are able to edit the config files to achieve the behaviour they want.
• Using Anaconda. Users can decide in the installation setup and that behaviour will be pre-set. Override possible via above methods.

My preferable settings

Which of the three settings we should support is questionable and probably a part of discussion. I would support the following behaviour (the lower number the more preferred):

1. Anaconda would enable to set one off the above behaviour which is respected in time.
2. Testing repos would be on in Beta, from Final RC on it would be off.
3. Testing repos always off.
4. Testing repos always on.

I am sending this to the test list for discussion.

I think you misunderstood my initial recommendation: I think that Anaconda should use only the stable repositories for installation, but that the installed system should have the updates-testing repository enabled prior to Final Freeze. So we stabilize the installation itself, but the resulting machines have access to testing packages on the next update.

Here's the mailing list thread, let's discuss there, it's more visible:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/MAAUGYLESR634VFGM2K6HE6PPOUQBYJX/

We also need to keep in mind that anaconda contains "(don't) install updates" checkbox in its gui and its behavior needs to be defined as well.

My initial thought is: disable that checkbox and make installing updates the default. If necessary for debugging, make a secret option of some sort.

We also need to keep in mind that anaconda contains "(don't) install updates" checkbox in its gui and its behavior needs to be defined as well.

My initial thought is: disable that checkbox and make installing updates the default. If necessary for debugging, make a secret option of some sort.

That option cannot be the default, as Anaconda is not guaranteed to have network access to the standard mirrors.

That option cannot be the default, as Anaconda is not guaranteed to have network access to the standard mirrors.

Install updates if available. If not, note that they aren't and move on. (Not even an error message. Just log it and maybe put a non-pop-up note on the screen.)

That option cannot be the default, as Anaconda is not guaranteed to have network access to the standard mirrors.

Install updates if available. If not, note that they aren't and move on. (Not even an error message. Just log it and maybe put a non-pop-up note on the screen.)

Silently not installing updates when asked to would be just about the worst outcome for security. If there was a temporary network hiccup, users would be assuming they had all the latest security updates when in reality they would not.

I didn't say "silently". I mean, I guess we could go with a scary error. In practice, there's a constant stream of security updates, and installing today's updates is better than not, but installing tomorrow's would be even better. Fedora's general default-to-off policy means that a freshly installed system doesn't have much of a target surface before it's configured to do something. Making sure updates are applied should be part of that after-first-boot process anyway.

Sigh, we seem to be discussing in two places. OK.

I'm mostly interested in what the checkbox does in regards to updates-testing if we decide to have updates-testing enabled at least during some point of time. If we want to have a different behavior for stable updates, I think that should get discussed separately.

Please also note that people install from DVDs or from private mirrors and might not want to pull stable updates from the internet even when it is available for many reasons. For example to have it fast, or to not waste internet bandwidth when not needed, or because they really really want the original system without the updates applied. We in QA can also have a lot of reasons when debugging things. Making good defaults is one thing, but completely removing the option is imho a bad idea.

Btw, defaults seem to be sane (updates are enabled by default on netinst, and disabled by default on DVD).

For me, the following behaviour makes sense:

1. In Anaconda, I can choose whether to install updates or not.
2. In Anaconda, I can choose whether to enable updates-testing (or easily add the repo)

The default behaviour:

1. Updates are pulled and installed. This mostly makes sense on a non-live system.
2. Updates-testing is disabled after Beta Freeze.
3. Updates-testing is enabled before Beta Freeze.

I tried to revive the discussion here:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/PCHDQAXZLIP2DLE5SMZMKLJKNFZUEHZO/

Please don't comment in this ticket, use the email thread, thank you.

I have asked for the changes in:
https://bugzilla.redhat.com/show_bug.cgi?id=1670091

well, that bug was closed nearly five years ago. let's call this fixed!