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

[NeilBrown]

On Fri, Aug 11 2017, Linus Torvalds wrote:

> On Fri, Aug 11, 2017 at 1:02 AM, NeilBrown <neilb at suse.com> wrote:
>>
>> What do you mean by "upgrade"?
>> Can I upgrade from 3.15 to 3.16-rc1?  If not, why not?
>
> Yes..
>
> Of course, bugs happen, and then they get fixed.
>
> But yes, even including things like -rc1 (or just "random untagged
> kernel of the day") you should
>
>  (a) feel safe in always upgrading to any higher version (I *hope* you
> can always also downgrade to a lower kernel version, but obviously at
> some point user space may start depending on newer features that
> simply don't exist in older kernels).
>
>  (b) also feel that if something breaks, it's a bug, and people will
> take it seriously and not dismiss it with some crazy "N+1 version"
> excuse.

I think the issue is that some of us would like a clearer statement on
what values of "some point" we will honor, and which values are
crazy-talk.

This related slightly to your comment:

>
> And then I say "if it took you three years to upgrade and notice a
> behavioral change that nobody else noticed, it's no longer _our_
> fault".

Can we also say "if you started depending on an API that has only been
in the kernel for 3 weeks and we had to revise it, then it not _our_
fault if you depend on it already"??

In the original post in this thread, Andy seemed to think that as long
as it gets "fixed before the next real release", we are safe.  Your
comments could be read to mean that you don't agree and that there is no
clear line at which we are safe.

You mentioned trust earlier:

> The whole point is that users are supposed to be able to *trust*
> the kernel.

I agree, but I think trust works best if it works both ways.  Can we
trust application developers not to depend on an API which hasn't
reached maturity?  I think we can if we tell them what we expect - what
constitutes "maturity" - and make it a reasonable expectation.  Do we
have to declare "maturity" the moment an API hits mainline (or hits
-next, or hits mailing lists), or can we negotiate a formal grace
period?

Yes, "no regressions" is an import rule that should remain, but there
has always been a loophole.  The loophole is "no harm, no foul".  If we
can negotiate an understanding that results in "no harm" from early
revisions to an API, then those revisions will not cause actual
regressions. "No foul".


But maybe I'm wrong and all the people talking about automatic tooling
to discover and highlight API changes in linux-next are on the right
track... or would be if everything actually went through linux-next.

Thanks,
NeilBrown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20170814/972fbab2/attachment.sig>