On Thu, 2019-09-12 at 05:28 +0100, Phil Wyett wrote: > On Wed, 2019-09-11 at 07:59 +0200, Kalev Lember wrote: > > On 9/10/19 14:58, Sumantro Mukherjee wrote: > > > As beta is about to be out,I was wondering when can we have the > > > Gnome > > > Test Day for this cycle? > > > The Fedora QA Test Day tracker is > > > https://pagure.io/fedora-qa/issue/588 > > > > How about right after the Beta release so that we have a few days > > between to give time for the 3.34.0 megaupdate update to go to stable > > and get a new branched compose? (Beta is shipping with 3.33.92, and > > we > > have 3.34.0 almost ready to go to bodhi). > > > > Maybe wait with the test day scheduling a bit until we know if the > > Beta > > is releasing on schedule or if it is going to be slipped? > > > > -- > > Kalev > > > > > > Hi, > > People who are installing the beta (1.1) then updating are getting 3.34 > due to the fact the testing repos are enabled. At present this update > does not go well, with wrongly large and missing icons all over the > place. > > I would have thought testing repos would be disabled in a beta, so > stable testing could be performed and testing updates only pulled in as > a conscious advanced user action? As someone else pointed out, the icon bug was not in fact in 3.34 but in a separate shared-mime-info update, and has already been fixed by a subsequent update. To answer the other question: the short answer is 'no'. The long answer is long. :) The key thing to understand is that, while Branched releases (development releases once they branch from Rawhide - 31 is the current 'Branched') and stable releases both use the updates-testing repository and the Bodhi feedback system, they use it for *different purposes*. For stable releases, the system of staging updates via updates-testing and Bodhi is there to *protect users from potentially bad updates*. We disable that repo by default and ask testers to volunteer to turn it on (or just install specific updates from it) so they can check updates before the "general population" of users get them. This is probably how you're using to thinking about Bodhi/updates-testing. For Branched, though, that's actually not what we use the system for at all. For Branched, the system is there to *protect the integrity of the build root and the distribution composes*. It's basically a safety valve for the *development process*, not for users. Our basic position is that anyone who installs a pre-release is a tester *by definition*. We tell people not to install pre-releases on production systems or use them for production purposes; if you install a Beta or other pre- release image we consider that sufficient all on its own as a declaration that you are here to help us test stuff and you understand that it might be broken. So for Branched, all users gets updates-testing enabled, but we *don't* use packages from updates-testing for doing composes (either the nightly composes, or release candidate composes), and we *don't* have them in the buildroot (unless someone submits an override). Thus the system is that the users get the packages and are expected to complain on Bodhi if they're broken (these days we also have some automated testing that can catch problems at this point), and that way we can block the package from going into the buildroot and/or the nightly composes and causing problems. If you want to be a 'selfish' pre-release user you can install a pre- release and turn off updates-testing manually, so you get the benefit of testing by all the other non-selfish pre-release users and get a somewhat more stable pre-release install. But the default is to have it enabled, for the good of Fedora as a whole. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
