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.
## 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.
--
Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ 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
