Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4759348imc; Mon, 25 Feb 2019 10:27:42 -0800 (PST) X-Google-Smtp-Source: AHgI3IbcfJmyopGqlO13LHN9kf0VQnjhUGUCJDAC08nWnWge4JUhvb3iHSqJtDsZcqAyyTVVx5Eo X-Received: by 2002:a17:902:3f81:: with SMTP id a1mr11130372pld.238.1551119262482; Mon, 25 Feb 2019 10:27:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551119262; cv=none; d=google.com; s=arc-20160816; b=xUkeV1fjjasBa4wsklJ0mmYqCDCCHtznEKyrSBLYqJmrppb//CnZwz2a3cld8WiEuw dFXd1Urn2bNFG/i8z9+0QHQY+20pd6hLMacqj2trdXOB5yYHS5KeIY2jTP99UpMDZzhD HucRxa9mBcWfKuXbxZJdJEoHU4beKEIBwqwQ3zXTkchFHZYxvDMy+gBozi9HOq7T7Lji o7AEMZpR4F8/OAD5rsmjXJ1WOgNylRiFqUhgkouJk2zEyveIli8uqrnIDa+uDzMfAgNp zQJ35t8DDvUNsSUgRc3IPrV3yog0ts99m+6gDyu2w27vZ5nURSrLS0P5vcPrLyZS8Xfs XB7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=0eZFFa+P54HSXW7/ucRCjsJDEfZ5oWUHvy3SThwMfow=; b=RxjLU4+nNwz0PH7YzULaBdNuzBNihg49/OxtkX/a6C2QNlZtX4SC0x5GuX5CvrQcUf g+1n7UGy9hDCrXpR4dwCoQT9Mffx2QC29SMUMmB+paaZXrxPNIK7YVe+JGF7gHO23kYb mb/a76B+scrftL2NtOP2nVXSJGK6c90oCGrH30WJ4SIbUUvro6yNBmkyoXsCZhnBIqKg K0Db6eFXaHth+JGs8WbKYPOQBOkHnuTdzOws6yW+e0Od17/U1554XLL606dnsEuisZrG xsdmFvCb+JcJWpNKuD5u9igddrrezNQKPnCVxLTtjrbLSQmK1uOYdTzZWVkYTgp/OxOO Adbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h64si9493180pge.55.2019.02.25.10.27.27; Mon, 25 Feb 2019 10:27:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728954AbfBYS0n (ORCPT + 99 others); Mon, 25 Feb 2019 13:26:43 -0500 Received: from ms.lwn.net ([45.79.88.28]:42578 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725936AbfBYS0m (ORCPT ); Mon, 25 Feb 2019 13:26:42 -0500 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id BDDAB304; Mon, 25 Feb 2019 18:26:41 +0000 (UTC) Date: Mon, 25 Feb 2019 11:26:40 -0700 From: Jonathan Corbet To: Zenghui Yu Cc: gregkh@linuxfoundation.org, akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] Documentation/process/howto: Update for 4.x -> 5.x versioning Message-ID: <20190225112640.50d6a2c5@lwn.net> In-Reply-To: <1551023123-5031-1-git-send-email-zenghuiyu96@gmail.com> References: <1551023123-5031-1-git-send-email-zenghuiyu96@gmail.com> Organization: LWN.net X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 24 Feb 2019 23:45:23 +0800 Zenghui Yu 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 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. > 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. > -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. > - 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. > 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. > -4.x.y are maintained by the "stable" team , and > +5.x.y are maintained by the "stable" team , 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. So what do you think? Can we maybe get a version that removes most (or all) of the explicit version numbers from this file? Thanks, jon