On 10/31/18 9:46 AM, Lukas Ruzicka wrote:
Hello,
I have been assigned to organize a discussion about this issue
https://pagure.io/fedora-qa/issue/567.
I have thought about some possibilities (see lower or the issue) how the
behaviour should be defined. I would like you to comment on it and add your
ideas to the material. I hope this discussion will result in one
transparent, documented and testable scenario in the end.
Thanks a lot.
Lukas
# 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.
_______________________________________________
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
My opinion is that Anaconda should only install from stable repo's.
The updates-testing repo's should be enabled after the install is
complete and the PC is restarted to the hard disk's new installation.
After all our procedures sometimes specify and at least imply to run the
tests prior to doing any updates. Once the tests are run updates can be
run as the last test and any resulting problems during subsequent
running of the testing regimen can be reported and/or troubleshot. We
may want to consider the order in which test are run and specify that
all test other that running update should be done prior to running
updates tests.
the Updates-testing repo should not be enabled by default in release
candidates or in the released version.
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
