On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > How about this: > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > I'm open for proposals on the wording. =) Well, I guess it depends on if you still want to implement it and then plan to roll it back or not... see below. > > > Rework the change so it's basically planning on making this change in > > f38. > > That makes it closer than currently, > defeating the purpose of letting people prepare. True, it possibly makes the timeline shorter. If thats a concern, perhaps you would consider just targeting f39 and for f38 just doing test days and reminders asking developers to test instead of changing it and then changing it back? > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > and decides if it can remain on in f38 and if not, it gets reverted and > > moved to f39. > > Not sure how it's better than reverting in branched f38 but not rawhide, > unless the goal is to hasten the change. It's better because it seems more direct and honest to me. It means you are landing a change and trying to get it done, not landing it to break people and then at the last minute after people rush to fix things, removing it again. I also suspect there will be some feet dragging due to this: "Oh, it's broken now, but they are going to revert it anyhow, so I won't do anything". > > > In the run up to f38 beta we could: > > > > * run a series of test days. perhaps one before you enable it in > > rawhide, one a month or two later and one right before f38 beta > > freeze? > > I'm for more test days. > There was one held already and I'm open for holding more in the future. > Plus I should attempt some side-tag mass-rebuild or equivalent, > but I, unfortunately, won't get to it until October at the earliest. Sure, understand time is low for everyone. ;( > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > tests on a compose or updates? This might be a good thing to try and do > > before landing it in rawhide. > > Sounds great if that's a possibility, but I don't know how to approach it. Perhaps Adam can chime in here... > > * setup a tracking bug to track the issues, so we can make a more > > informed decision before f38 beta. > > > > Thoughts? > > If the core of your proposal is > * make it happen in f38 and revert and push back to f39 only if necessary > as opposed to > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > but not f38 branched (the current proposal) > then I can't say I understand what you are trying to achieve with > that. I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just kidding, it will not take effect until next cycle. That just seems to be dishonest to our users. > IMO it makes the switch less certain, more frantic and more abrupt, > while I was trying to smoothen it out in time as far as possible. I don't think it's possible to cleanly spread out a change like this over more than 1 long fedora cycle. > > So +1 on all the accompanying activities possible, > -1 on expediting the switch. ok. I'm not sure where the rest of fesco is on this, but I guess we will see. :) Thanks for listening. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
