Hi Jon, On Tue, Feb 26, 2019 at 2:26 AM Jonathan Corbet <corbet@xxxxxxx> wrote: > > On Sun, 24 Feb 2019 23:45:23 +0800 > Zenghui Yu <zenghuiyu96@xxxxxxxxx> wrote: > > > As linux-5.0 is coming up soon, the howto.rst document can be > > updated for the new kernel version. Change all 4.x references > > to 5.x now. > > > > Signed-off-by: Zenghui Yu <zenghuiyu96@xxxxxxxxx> > > Overall: I think there's value in having the docs reflect current > numbers, though it would be better if the docs as a whole were kept > current at the same time. howto.rst hasn't been updated yet, so this > attention is welcome - thanks for taking a look at it. That said, I > really think we can do a little better. Thanks for your reviewing and nice suggestions. Now I have realized that simply changing version numbers in howto.rst (like what I've done ...) is shortsighted. And yeah, we can do it better. > > Documentation/process/howto.rst | 24 ++++++++++++------------ > > 1 file changed, 12 insertions(+), 12 deletions(-) > > > > diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst > > index f16242b..19001e2 100644 > > --- a/Documentation/process/howto.rst > > +++ b/Documentation/process/howto.rst > > @@ -235,16 +235,16 @@ Linux kernel development process currently consists of a few different > > main kernel "branches" and lots of different subsystem-specific kernel > > branches. These different branches are: > > > > - - main 4.x kernel tree > > - - 4.x.y -stable kernel tree > > + - main 5.x kernel tree > > + - 5.x.y -stable kernel tree > > - subsystem specific kernel trees and patches > > - - the 4.x -next kernel tree for integration tests > > + - the 5.x -next kernel tree for integration tests > > One thing I think we can do is to simply get rid of version numbers in a > lot of places and make this process easier when 6.x comes around. What > this is really trying to say is that we have: > > - Linus's mainline tree > - Various stable trees with multiple major numbers > - Subsystem-specific trees > - linux-next > > If we could rework this along those lines, it will more accurately > reflect reality and not require updating next time. Obviously a better classification. Will follow your suggestion and modify it. > > -4.x kernel tree > > +5.x kernel tree > > ~~~~~~~~~~~~~~~ > > > > -4.x kernels are maintained by Linus Torvalds, and can be found on > > -https://kernel.org in the pub/linux/kernel/v4.x/ directory. Its development > > +5.x kernels are maintained by Linus Torvalds, and can be found on > > +https://kernel.org in the pub/linux/kernel/v5.x/ directory. Its development > > process is as follows: > > And here too I think we can just say "mainline" and that they can be > found at https://kernel.org/ or in the repo. Will modify. > > - As soon as a new kernel is released a two weeks window is open, > > @@ -277,21 +277,21 @@ mailing list about kernel releases: > > released according to perceived bug status, not according to a > > preconceived timeline."* > > > > -4.x.y -stable kernel tree > > +5.x.y -stable kernel tree > > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Kernels with 3-part versions are -stable kernels. They contain > > relatively small and critical fixes for security problems or significant > > -regressions discovered in a given 4.x kernel. > > +regressions discovered in a given 5.x kernel. > > Here too, especially since most of the outstanding stable kernels won't > be 5.x for a long time. Yes. Actually, I hesitated too when I was changing "4.x.y -stable kernel tree" to "5.x.y -stable kernel tree" :) Using "stable trees" instead will be better. > > This is the recommended branch for users who want the most recent stable > > kernel and are not interested in helping test development/experimental > > versions. > > > > -If no 4.x.y kernel is available, then the highest numbered 4.x > > +If no 5.x.y kernel is available, then the highest numbered 5.x > > kernel is the current stable kernel. > > ...and this, I believe, is misleading at best. I'd just take that > sentence out. Yes, I'll delete it. > > -4.x.y are maintained by the "stable" team <stable@xxxxxxxxxxxxxxx>, and > > +5.x.y are maintained by the "stable" team <stable@xxxxxxxxxxxxxxx>, and > > are released as needs dictate. The normal release period is approximately > > two weeks, but it can be longer if there are no pressing problems. A > > security-related problem, instead, can cause a release to happen almost > > @@ -326,10 +326,10 @@ revisions to it, and maintainers can mark patches as under review, > > accepted, or rejected. Most of these patchwork sites are listed at > > https://patchwork.kernel.org/. > > > > -4.x -next kernel tree for integration tests > > +5.x -next kernel tree for integration tests > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > -Before updates from subsystem trees are merged into the mainline 4.x > > +Before updates from subsystem trees are merged into the mainline 5.x > > tree, they need to be integration-tested. For this purpose, a special > > testing repository exists into which virtually all subsystem trees are > > pulled on an almost daily basis: > > linux-next is called "linux-next"; we should just use that name. Will modify. > So what do you think? Can we maybe get a version that removes most (or > all) of the explicit version numbers from this file? Actually, jon, you have already kindly pointed out everywhere to be noticed in this patch. What I need to do is just follow your detailed suggestions and send a V3 :) And I think all of the explicit version numbers can be removed. Many thanks, zenghui
