Re: [Ksummit-discuss] [MAINTAINER TOPIC] ABI feature gates?

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 3219 bytes --]

On Wed, Aug 09 2017, Linus Torvalds wrote:

> On Tue, Aug 8, 2017 at 5:00 PM, NeilBrown <neilb@suse.com> wrote:
>>
>> I think this is primarily a social/communication issue.  We need to know
>> what is expected and what can be trusted.  We need clear rules that
>> everyone knows and that work for everyone.  Currently we have (fairly)
>> clear rules that work fairly well in many cases, but can be problematic.
>>
>> The rules, as you outline, are that users should not experience
>> regressions from one released kernel to a subsequent released kernel.
>> So people working on -rc kernels can expect to experience regressions.
>> Also kernel devs are free to create theoretical regressions as long an
>> no-one experiences them.
>>
>> My strawman is to suggest that we relax this.
>
> No.
>
> The whole "no regressions" is a hard rule, and it will remain so.
> It's pretty much the only really hard rule we have, and I will
> continue to insist on it.
>
> There are no loopholes. No "but it's been only one release". No, no,
> no. The whole point is that users are supposed to be able to *trust*
> the kernel. If we do something, we keep on doing it.

I completely agree with the "trust" issue.  I don't think my proposal
violates it.  It just changes the names of the things that can be
trusted.  You could easily change them back.
e.g.
- When you are ready to release 4.13, call it 4.13-pre1 instead
- You then open the merge window and pull changes onto this base
  working towards 4.14-rc1.  Just as you currently do, you accept
  changes to the API for interfaces that have not appeared in a
  released kernel (and 4.13 hasn't been released at this point).
- Greg takes over 4.13-pre and applied patches tagged for "stable"
  exactly as he currently does, except that he calls the first
  few releases "4.13-pre2" and "4.13-pre3" etc.  These "stable"
  patches might include changes to APIs that were introduced since 4.12,
  changes that you have already included in 4.14-rcX.
- After you release 4.14-pre1, the next kernel that Greg releases
  in the 4.13-preX series gets called "4.13", and subsequent kernels in
  that series are "4.13.1" etc as normal.

With this pattern, people can still trust an X.Y kernel, possible more
than they currently do (how many people wait for X.Y.3 before they will
move?).   With this pattern, we still get an X.Y every 2 months or so
(except for one 4 month gap at the change-over).
The main difference is that we are a bit more honest about how long it
takes to bake a kernel before it is ready.  We also get more time to
document and fix broken APIs.

"pre" is probably weird, and "rc" doesn't really mean "release
candidate" these days, except for rc7.  Maybe you could call your "rc"
kernels dev1, dev2, etc. Then Greg could use "rcX" for the real release
candidates.  But naming is hard.

>
> And if it makes it harder to add new user-visible interfaces, then
> that's a *good* thing.

I think the point is that it is currently too easy to add user-visible
changes (extra flags, etc), and none of the proposals actually make it
harder.  They just try to make them more visible.  The proposal makes it
harder in that it forces an extra 2 month delay.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]