Thanks for working to improve our documentation! Naturally, I have
some comments, the first of which being to run
scripts/get_maintainer.pl on your patches to get the list of people
you should send them to. Then cut-and-paste it rather then typoing
it by hand :) Dante Strock <dantestrock@xxxxxxxxxxx> writes:
From 1fbe3d56d604a0f8a87ed1d3f092b84c2fab4392 Mon Sep 17
00:00:00 2001 From: Dante Strock <dantestrock@xxxxxxxxxxx> Date:
Sat, 7 Jun 2025 09:29:36 +0100 Subject: [PATCH]
Documentation/process/: Change 5.x to 6.x; clarify terms; added
note. From: Dante Strock <dantestrock@xxxxxxxxxxx> As a possible
suggestion, might it be worthwhile adding a terminology section
specific to each section of the kernel documentation? That way
developers have a handy reference to refer back to for terms
they might not understand. ---
Documentation/process/2.Process.rst: - Changed some instances of
5.x to 6.x(though kept some instances of 5.x that are used in
examples). - Clarified the term "rc" in brackets. - Added a
notice for people installing Git or Mercurial to check their
distribution repository for the latest version of the software.
Signed-off-by: Dante Strock <dantestrock@xxxxxxxxxxx> ---
Documentation/process/2.Process.rst | 26
+++++++++++++++----------- 1 file changed, 15 insertions(+), 11
deletions(-)
This is backward - the changelog goes above the "---" line, any
additional comments go below. A bulleted list like the above is a
good sign that the patch should be split up - patches should do one
thing.
diff --git a/Documentation/process/2.Process.rst
b/Documentation/process/2.Process.rst index
ef3b116492df..70f8a6603454 100644 ---
a/Documentation/process/2.Process.rst +++
b/Documentation/process/2.Process.rst @@ -18,17 +18,17 @@ major
kernel release happening every two or three months. The recent
release history looks like this: ====== ================= - 5.0
March 3, 2019 - 5.1 May 5, 2019 - 5.2 July 7, 2019 - 5.3
September 15, 2019 - 5.4 November 24, 2019 - 5.5 January 6, 2020
+ 6.10 July 14, 2024 + 6.11 September 15, 2024 + 6.12 November
17, 2024 + 6.13 January 20, 2025 + 6.14 March 24, 2025 + 6.15
May 25, 2025 ====== ================= -Every 5.x release is a
major kernel release with new features, internal +Every 6.x
release is a major kernel release with new features, internal
API changes, and more. A typical release can contain about
13,000 -changesets with changes to several hundred thousand
lines of code. 5.x is +changesets with changes to several
hundred thousand lines of code. 6.x is the leading edge of Linux
kernel development; the kernel uses a rolling development model
which is continually integrating major changes.
I do not object to these change and could apply this, but it might
be nice at some point to rephrase this stuff so that we don't end up
doing these updates repeatedly. After all, we'll be at 7.x within a
year...
@@ -48,9 +48,9 @@ detail later on). The merge window lasts for
approximately two weeks. At the end of this time, Linus Torvalds
will declare that the window is closed and release the -first of
the "rc" kernels. For the kernel which is destined to be 5.6,
+first of the "rc"("release candidate") kernels. For the kernel
which is destined to be 6.16,
This is a separate change. But, of course, yesterday's 6.16-rc1 is
in no way a "release candidate". It's really just the naming scheme
that Linus uses for his testing releases, calling them "release
candidates" muddies the water and risks reigniting old debates.
+Note that not all Linux distributions have the latest version
of Git +or Mercurial available in their repositories. Consult
the package +maintainer for your distribution to get the package
updated or +download it directly from the website.
I almost wonder if the references to Mercurial shouldn't just come
out; I am not aware of anybody using it for kernel work at this
point. I'm also not aware of anybody who has run into trouble
because their distribution lacked a shiny new version of Git. I'm
not sure we want to encourage people to bug their distributors to
accelerate updates? Is this paragraph solving a specific problem
that you have encountered? Thanks, jon
Hello,
Apologies about the sending of the original email: I had been doing a
lot of fiddling that morning to get things setup and by the time I sent
the email, had failed to check the address before sending. I'll keep
this in mind for next time and will be more diligent. Thank you as well
for the feedback on my changes. I've taken note of these for future
reference.
I agree with you on the first point you make about the release numbers.
I suppose we could remove the example version history entirely so as to
avoid updating version numbers constantly, or stick with one version
number(e.g. 6.0, 6.1, 6.2, 6.3, etc.) as an example and keep it that
way. I thought it would've been good to update it to keep the page
fresh(as the versions listed were between 2019-2020; we're now in 2025),
but I can see the point you're making and a rephrase might be better so
as to avoid constantly changing it.
I've always read and understood "rc" to mean "release candidate" and
thought it would be good, as a general principle, to clarify what
abbreviated terms like "rc" meant. If this creates the risk of confusion
and unnecessary debate, then do not include it. This is partly the
reason why I suggested a terminology section specific to each section of
the documentation that could help clarify technical or abbreviated terms
that readers might not have encountered before. In this case, "rc" is
not that much of a deal to warrant a place in a terminology section, but
in other sections of the documentation which can get very technical, it
may well be worth it.
I see very little mention online of Mercurial either: Git seems to be
the standard VCS nowadays. It might be wise to simply point people to
Git only, that way everybody uses the same tools and it streamlines
development for the whole kernel. As for keeping the software
up-to-date: I put it in as I've found a lot of mentions online of
packages in some distribution repos being outdated, though with software
like Git that is heavily used, this really shouldn't be an issue, but I
thought it still to be worth noting just in case.
Hope this explains my patch well enough.
Thanks,
Dante
