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@xxxxxxxxxx> escribió:
On Wed, Oct 31, 2018 at 10:01 AM Kamil Paral <kparal@xxxxxxxxxx> wrote:
>
> On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka <lruzicka@xxxxxxxxxx> 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@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
_______________________________________________ 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
