On Wed, Sep 14, 2022 at 6:40 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > 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". If this helps, from the perspective of tracking rawhide, we flip the switch and don't revert it. So the "they'll revert it" argument doesn't work at least for rawhide. > > > 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. That's a reason why my initial thread [1] has been named "Landing a larger-than-release change (distrusting SHA-1 signatures)": flipping the switch is the easy part, unfortunately. > > 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. [1] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ _______________________________________________ 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
