On Wed, Sep 14, 2022 at 6:40 PM Kevin Fenzi <kevin(a)scrye.com> 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(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. =)
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@lists.fedoraproject.o...