Ideas for discussion (Issue #567)

[Lukas Ruzicka]

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.



-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

<https://www.redhat.com>

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

[Kamil Paral]

On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka <lruzicka(a)redhat.com&gt; 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
>  
I agree with Stephen at https://pagure.io/fedora-qa/issue/567#comment-538601
, this might be a misunderstanding. I don't think we need to change when
updates-testing is enabled/disabled in the installed system. That seems to
be working quite fine. But we want to define how anaconda should behave
when installing from online repos, whether it should use updates-testing
for installation or not, or when.

So the possible options probably are:
* always disabled during installation
* always enabled during installation up to the final RC
* respect the default values in fedora-repos (enabled only as long as it is
enabled in the installed system). Note that this is likely decided at
compose time.

And then we need to define what happens when the user enables/disables
additional updates using the checkbox in "installation source" spoke. Or,
in case we keep updates-testing enabled at least sometime, whether the GUI
should change somehow to reflect that.

[Julen Landa Alustiza]

I'm agree with stephen & kparal too.

For anaconda, I would prefer always disabled or respect fedora-release

El mié., 31 oct. 2018 15:01, Kamil Paral <kparal(a)redhat.com&gt; escribió:

>  On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka
> <lruzicka(a)redhat.com&gt; 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
> >
>
>  I agree with Stephen at
>  https://pagure.io/fedora-qa/issue/567#comment-538601 , this might be a
>  misunderstanding. I don't think we need to change when updates-testing is
>  enabled/disabled in the installed system. That seems to be working quite
>  fine. But we want to define how anaconda should behave when installing from
>  online repos, whether it should use updates-testing for installation or
>  not, or when.
>
>  So the possible options probably are:
>  * always disabled during installation
>  * always enabled during installation up to the final RC
>  * respect the default values in fedora-repos (enabled only as long as it
>  is enabled in the installed system). Note that this is likely decided at
>  compose time.
>
>  And then we need to define what happens when the user enables/disables
>  additional updates using the checkbox in "installation source" spoke. Or,
>  in case we keep updates-testing enabled at least sometime, whether the GUI
>  should change somehow to reflect that.
>
>  _______________________________________________
>  test mailing list -- test(a)lists.fedoraproject.org
>  To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>

[Stephen Gallagher]

On Wed, Oct 31, 2018 at 10:01 AM Kamil Paral <kparal(a)redhat.com&gt; wrote:
>  On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka <lruzicka(a)redhat.com&gt; 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
>
>
>  I agree with Stephen at https://pagure.io/fedora-qa/issue/567#comment-538601 , this might
> be a misunderstanding. I don't think we need to change when updates-testing is
> enabled/disabled in the installed system. That seems to be working quite fine. But we want
> to define how anaconda should behave when installing from online repos, whether it should
> use updates-testing for installation or not, or when.
>
>  So the possible options probably are:
>  * always disabled during installation
>  * always enabled during installation up to the final RC
>  * respect the default values in fedora-repos (enabled only as long as it is enabled in
> the installed system). Note that this is likely decided at compose time.
>
>  And then we need to define what happens when the user enables/disables additional updates
> using the checkbox in "installation source" spoke. Or, in case we keep
> updates-testing enabled at least sometime, whether the GUI should change somehow to
> reflect that. 

I want to cast a vote that anaconda should never enable the
updates-testing repository absent an explicit user request (such as
adding them as supplementary install sources). The advantage here is
that we are far more likely to succeed with installations and then
testing will take place once they have a viable starting point.

[Julen Landa Alustiza]

that will allow us to install a working enviroment if there is something
broken on u-t or if there is something broken on the compose and fixed on
u-t since we will be able to add the repo during install process.

Would be great to have a disabled by default checkbox on additional repos
windows so we don't have to add manually u-t repo when the broken package
is on the compose

El mié., 31 oct. 2018 15:09, Stephen Gallagher <sgallagh(a)redhat.com&gt;
escribió:

>  On Wed, Oct 31, 2018 at 10:01 AM Kamil Paral
> <kparal(a)redhat.com&gt; wrote:
>  >
>  > On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka <lruzicka(a)redhat.com&gt;
>  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
>  >
>  >
>  > I agree with Stephen at
>  https://pagure.io/fedora-qa/issue/567#comment-538601 , this might be a
>  misunderstanding. I don't think we need to change when updates-testing is
>  enabled/disabled in the installed system. That seems to be working quite
>  fine. But we want to define how anaconda should behave when installing from
>  online repos, whether it should use updates-testing for installation or
>  not, or when.
>  >
>  > So the possible options probably are:
>  > * always disabled during installation
>  > * always enabled during installation up to the final RC
>  > * respect the default values in fedora-repos (enabled only as long as it
>  is enabled in the installed system). Note that this is likely decided at
>  compose time.
>  >
>  > And then we need to define what happens when the user enables/disables
>  additional updates using the checkbox in "installation source" spoke. Or,
>  in case we keep updates-testing enabled at least sometime, whether the GUI
>  should change somehow to reflect that.
>
>
>  I want to cast a vote that anaconda should never enable the
>  updates-testing repository absent an explicit user request (such as
>  adding them as supplementary install sources). The advantage here is
>  that we are far more likely to succeed with installations and then
>  testing will take place once they have a viable starting point.
>  _______________________________________________
>  test mailing list -- test(a)lists.fedoraproject.org
>  To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>

[Lukas Ruzicka]

Oh, so I did not get it.
I agree that anaconda only should install from stable repos unless told
otherwise specifically.
 Luk

On Wed, Oct 31, 2018 at 3:24 PM Julen Landa Alustiza <julen(a)zokormazo.info&gt;
wrote:

>  that will allow us to install a working enviroment if there is
> something
>  broken on u-t or if there is something broken on the compose and fixed on
>  u-t since we will be able to add the repo during install process.
>
>  Would be great to have a disabled by default checkbox on additional repos
>  windows so we don't have to add manually u-t repo when the broken package
>  is on the compose
>
>  El mié., 31 oct. 2018 15:09, Stephen Gallagher <sgallagh(a)redhat.com&gt;
>  escribió:
>
> > On Wed, Oct 31, 2018 at 10:01 AM Kamil Paral <kparal(a)redhat.com&gt; wrote:
> > >
> > > On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka <lruzicka(a)redhat.com&gt;
> > 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
> > >
> > >
> > > I agree with Stephen at
> > https://pagure.io/fedora-qa/issue/567#comment-538601 , this might be a
> > misunderstanding. I don't think we need to change when updates-testing is
> > enabled/disabled in the installed system. That seems to be working quite
> > fine. But we want to define how anaconda should behave when installing from
> > online repos, whether it should use updates-testing for installation or
> > not, or when.
> > >
> > > So the possible options probably are:
> > > * always disabled during installation
> > > * always enabled during installation up to the final RC
> > > * respect the default values in fedora-repos (enabled only as long as
> > it is enabled in the installed system). Note that this is likely decided at
> > compose time.
> > >
> > > And then we need to define what happens when the user enables/disables
> > additional updates using the checkbox in "installation source" spoke. Or,
> > in case we keep updates-testing enabled at least sometime, whether the GUI
> > should change somehow to reflect that.
> >
> >
> > I want to cast a vote that anaconda should never enable the
> > updates-testing repository absent an explicit user request (such as
> > adding them as supplementary install sources). The advantage here is
> > that we are far more likely to succeed with installations and then
> > testing will take place once they have a viable starting point.
> > _______________________________________________
> > test mailing list -- test(a)lists.fedoraproject.org
> > To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
> > 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/[e-mail]
> >
>  _______________________________________________
>  test mailing list -- test(a)lists.fedoraproject.org
>  To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

<https://www.redhat.com>

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

[Lukas Ruzicka]

However, I would support the idea that Anaconda could have an easy way to
enable testing repositories by clicking on a checkbox, similarly to "Don't
install the latest available software updates ..."


On Wed, Oct 31, 2018 at 3:36 PM Lukas Ruzicka <lruzicka(a)redhat.com&gt; wrote:

>  Oh, so I did not get it.
>  I agree that anaconda only should install from stable repos unless told
>  otherwise specifically.
>   Luk
>
>  On Wed, Oct 31, 2018 at 3:24 PM Julen Landa Alustiza <julen(a)zokormazo.info&gt;
>  wrote:
>
> > that will allow us to install a working enviroment if there is something
> > broken on u-t or if there is something broken on the compose and fixed on
> > u-t since we will be able to add the repo during install process.
> >
> > Would be great to have a disabled by default checkbox on additional repos
> > windows so we don't have to add manually u-t repo when the broken package
> > is on the compose
> >
> > El mié., 31 oct. 2018 15:09, Stephen Gallagher <sgallagh(a)redhat.com&gt;
> > escribió:
> >
> >> On Wed, Oct 31, 2018 at 10:01 AM Kamil Paral <kparal(a)redhat.com&gt; wrote:
> >> >
> >> > On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka <lruzicka(a)redhat.com&gt;
> >> 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
> >> >
> >> >
> >> > I agree with Stephen at
> >> https://pagure.io/fedora-qa/issue/567#comment-538601 , this might be a
> >> misunderstanding. I don't think we need to change when updates-testing is
> >> enabled/disabled in the installed system. That seems to be working quite
> >> fine. But we want to define how anaconda should behave when installing from
> >> online repos, whether it should use updates-testing for installation or
> >> not, or when.
> >> >
> >> > So the possible options probably are:
> >> > * always disabled during installation
> >> > * always enabled during installation up to the final RC
> >> > * respect the default values in fedora-repos (enabled only as long as
> >> it is enabled in the installed system). Note that this is likely decided at
> >> compose time.
> >> >
> >> > And then we need to define what happens when the user enables/disables
> >> additional updates using the checkbox in "installation source" spoke.
> Or,
> >> in case we keep updates-testing enabled at least sometime, whether the GUI
> >> should change somehow to reflect that.
> >>
> >>
> >> I want to cast a vote that anaconda should never enable the
> >> updates-testing repository absent an explicit user request (such as
> >> adding them as supplementary install sources). The advantage here is
> >> that we are far more likely to succeed with installations and then
> >> testing will take place once they have a viable starting point.
> >> _______________________________________________
> >> test mailing list -- test(a)lists.fedoraproject.org
> >> To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
> >> 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/[e-mail]
> >>
> > _______________________________________________
> > test mailing list -- test(a)lists.fedoraproject.org
> > To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
> > 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/[e-mail]
> >
>
>
>  --
>
>  Lukáš Růžička
>
>  FEDORA QE, RHCE
>
>  Red Hat
>
>  <https://www.redhat.com>
>
>  Purkyňova 115
>
>  612 45 Brno - Královo Pole
>
>  lruzicka(a)redhat.com
>  TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
>  

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

<https://www.redhat.com>

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>   
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)