From: Thorsten Leemhuis <linux@leemhuis.info>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
stable@vger.kernel.org, workflows@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
Date: Thu, 11 Apr 2024 08:50:19 +0200 [thread overview]
Message-ID: <898e813d-883c-4ccb-91ad-03aff40d59e3@leemhuis.info> (raw)
In-Reply-To: <2024041127-attach-removed-f9f0@gregkh>
On 11.04.24 08:10, Greg Kroah-Hartman wrote:
> On Thu, Apr 11, 2024 at 07:50:29AM +0200, Thorsten Leemhuis wrote:
>> On 11.04.24 07:30, Greg Kroah-Hartman wrote:
>>> On Thu, Apr 11, 2024 at 07:25:05AM +0200, Thorsten Leemhuis wrote:
>>>>
>>>> - Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
>>>> + Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
>>>
>>> I do not know what "stable mainline release" means here, sorry. "after
>>> 4 weeks in mainline" means "after in Linus's tree for 4 weeks, but
>>> Linus's tree is not "stable mainline".
>>
>> I meant a proper mainline release like 6.7 or 6.8 to make it obvious
>> that this does not mean a "pre-release".
>>
>> I actually had used the term "proper mainline release" earlier in a
>> draft, but a quick search on the net showed that this is not really used
>> out there. "stable mainline release" is not popular either, but seemed
>> to be a better match; I also considered "final mainline release", but
>> that felt odd.
>>
>> It feels like there must be some better term my mind just stumbles to
>> come up with. Please help. :-D
>
> Well, what is the goal here? Just put it in words, I have seen stuff
> like:
> Cc: <stable@vger.kernel.org> # wait until -rc3
> Cc: <stable@vger.kernel.org> # wait until 6.1 is released
> Cc: <stable@vger.kernel.org> # after -rc2
>
> and so on.
>
> Just pick a specific time/release might be better? "after X weeks" is
> assuming that we all know and remember how many weeks something
> happened...
My reasoning was: a developer that submits a patch has no full control
over when the patch mainlined -- and plans sometimes change, too.
So a patch that was meant to go into 6.1-rc with a tag like "# wait
until 4 weeks after 6.1 is released" might only be mainlined for 6.2-rc1
-- and then the tag does not express the developers intention.
But that might be a corner case that we could ignore. So maybe "# wait
until 4 weeks after 6.1 is released" is the better example (from what
I've heard something like that is what developer would like to have
sometimes).
Ciao, Thorsten
next prev parent reply other threads:[~2024-04-11 6:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 5:25 [PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport' Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy Thorsten Leemhuis
2024-04-11 5:27 ` Greg Kroah-Hartman
2024-04-11 5:25 ` [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport" Thorsten Leemhuis
2024-04-11 5:29 ` Greg Kroah-Hartman
2024-04-11 6:59 ` Thorsten Leemhuis
2024-04-11 7:40 ` Greg Kroah-Hartman
2024-04-11 7:50 ` Thorsten Leemhuis
2024-04-11 9:13 ` Greg Kroah-Hartman
2024-04-11 9:19 ` Geert Uytterhoeven
2024-04-11 9:53 ` Greg Kroah-Hartman
2024-04-11 9:57 ` Thorsten Leemhuis
2024-04-11 15:12 ` Greg Kroah-Hartman
2024-04-11 5:25 ` [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example Thorsten Leemhuis
2024-04-11 5:30 ` Greg Kroah-Hartman
2024-04-11 5:50 ` Thorsten Leemhuis
2024-04-11 6:10 ` Greg Kroah-Hartman
2024-04-11 6:50 ` Thorsten Leemhuis [this message]
2024-04-11 6:56 ` Greg Kroah-Hartman
2024-04-11 7:18 ` Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags Thorsten Leemhuis
2024-04-11 5:31 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=898e813d-883c-4ccb-91ad-03aff40d59e3@leemhuis.info \
--to=linux@leemhuis.info \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox