On Wed, Sep 13, 2023 at 09:40:34AM +0200, Donald Buczek wrote:
> On 9/12/23 10:15 AM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 12, 2023 at 09:47:40AM +0200, Donald Buczek wrote:
> >> On 9/11/23 15:54, Greg Kroah-Hartman wrote:
> >>> We have never guaranteed that Kconfig options will never change in
> >>> stable kernel releases, sorry.
> >>
> >> I didn't want to imply that and I don't expect it.
> >>
> >> It's just _if_ stable really gradually opens up to anything (like code
> >> removals, backports of new features, heuristically or AI selected
> >> patches, performance patches) it IMO loses its function and we could
> >> as well follow mainline, which, I think, is what you are recommending
> >> anyway.
> >
> > When code is removed from stable kernel versions, it is usually for very
> > good reasons, like what happened here. Sorry I can't go into details,
> > but you really wanted this out of your kernel, this was a bugfix :)
>
> Thanks. I understand that this topic can not be discussed and take your word.
>
> >> We've had bad surprises with more or less every mainline releases
> >> while updates in a stable series could be trusted to go 99% without
> >> thinking. Keeping productions systems on some latest stable gave us
> >> the time to identifying and fix problems with newer series before
> >> making it the designated series for all systems. This worked well.
> >>
> >> If the policy of stable gradually changes, that's tough luck for us. I
> >> wouldn't complain but it would be good to know. And maybe
> >> Documentation/process/stable-kernel-rules.rs should be reviewed.
> >
> > If the policy changes, we will change that document, but for now, we are
> > backporting only bugfixes that are found through explicit tagging,
> > developer requests, manual patch review, and "compare this commit to
> > past commits that were accepted" matching which then gets manual review.
>
> Hmmmm, okay. For an apparent counter-example, just yesterday we had to learn about 4921792e04f2125b ("drm/amdgpu: install stub fence into potential unused fence pointers") [1] the hard way [2].
>
> [1]: https://lore.kernel.org/stable/20230724012419.2317649-13-sashal@xxxxxxxxxx/t/#u
> [2]: https://gitlab.freedesktop.org/drm/amd/-/issues/2820#note_2080918
Bugs happen, testing is best, we are just human and we can never claim
nothing will ever break at any point in time.
All we can do is fix things as quick as possible, which is what we try
to do.
> Does "compare this commit to past commits that were accepted" include anything AUTOSELected?
That is what the AUTOSEL patches are, that marking is to show this is
how they were chosen. There's a bunch of papers and presentations on
how that process works over many years if you are curious about the
details.
thanks,
greg k-h
