On Wed, Aug 09 2017, Linus Torvalds wrote: > On Tue, Aug 8, 2017 at 5:00 PM, NeilBrown 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