On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
How about this:
Drop the term 'jump scare' entirely. IMHO it just sounds bad.
I'm open for proposals on the wording. =)
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.
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.
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.
* 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.
* 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.
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.
So +1 on all the accompanying activities possible,
-1 on expediting the switch.