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(a)scrye.com>
> 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
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
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
> 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
> informed decision before f38 beta.
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
I don't care for "Here's a change, adjust to it please! Hurry!" Oh,
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
Thanks for listening.