workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thorsten Leemhuis <linux@leemhuis.info>
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:56:55 +0200	[thread overview]
Message-ID: <2024041130-trickster-naturist-0448@gregkh> (raw)
In-Reply-To: <898e813d-883c-4ccb-91ad-03aff40d59e3@leemhuis.info>

On Thu, Apr 11, 2024 at 08:50:19AM +0200, Thorsten Leemhuis wrote:
> 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.

I've normally seen patches end up in Linus's tree "too early" more often
(i.e. cc: stable for stuff that has never been in a stable tree yet),
but sure, I can see how changes can also take too long.

> 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).

Yes, referencing off of a fixed point like a release is best as that's
much easier for humans to calculate.

Also because, the original "after 4 weeks", doesn't give me a reference
point to judge what the starting time is easily.  Yes, I have tools for
that, but most people don't.

So how about changing it to use the "fixed point" reference please?  The
phrasing "after -rc3" is probably what most people almost always want
anyway, given the huge churn that -rc1 is.

thanks,

greg k-h

  reply	other threads:[~2024-04-11  6:56 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
2024-04-11  6:56           ` Greg Kroah-Hartman [this message]
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=2024041130-trickster-naturist-0448@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --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