All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Sasha Levin <sashal@kernel.org>,
	ksummit@lists.linux.dev
Subject: Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches
Date: Mon, 15 Jul 2024 17:10:46 +0200	[thread overview]
Message-ID: <2024071537-unskilled-boney-2fb6@gregkh> (raw)
In-Reply-To: <87h6cqya32.fsf@trenco.lwn.net>

On Mon, Jul 15, 2024 at 09:00:01AM -0600, Jonathan Corbet wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Mon, Jul 15, 2024 at 04:34:19PM +0200, Alexandre Belloni wrote:
> >> I'm very surprised that it didn't cross anyone's mind yet that
> >> contributors and maintainers don't bother using Cc: stable because they
> >> don't care about stable for various reasons. So the behaviour is nether
> >> good nor bad and doesn't have to be penalized.
> >
> > Totally true.  The first rule of the stable tree is "it will not put
> > additional burden on any developer or maintainer that doesn't want to
> > participate in it."  So if you don't want to deal with it, wonderful,
> > don't take anything and just don't worry about it.
> 
> I must confess I've been wondering about this, since I've seen the above
> policy expressed a number of times over the years.  Stable participation
> is entirely optional.  But then this conversation has included things
> like:
> 
> > All our documentation explicitly says that a stable tag is a *must*,
> > we've been nagging folks to add it when they haven't, and we give them
> > the spiel whenever we're asked why a certain fixes-only commit didn't
> > make it into the stable trees.
> 
> Sasha, https://lore.kernel.org/all/ZpQbQa-_8GkoiPhE@sashalap
> 
> > Anyway, if people want to stick to the current, documented, process,
> > great, but as-is, trying to get people to follow that is rough and not
> > really working.
> 
> Greg, https://lore.kernel.org/all/2024071528-cahoots-reacquire-9eab@gregkh

I say this as many maintainers/developers get the "Fixes:" tag stuff
mixed up.  We had a very senior/core developer email us about this just
this weekend, they thought they were following the proper process and
didn't realize that "Cc: stable@" was the proper way instead.

That's what I mean, for people who _WANT_ to participate, they get it
wrong, as Linus points out, none of us read the documentation we have :(

> So, to me, the real question here is: what is the actual policy?  Are
> developers and maintainers expected to put in stable tags the way they
> are expected to add Signed-off-by, or is it a fully optional practice?
> In the latter case, I'm not sure how much good messing with the tags
> will do.

It's optional, but if you DO want to do it right, please cc: stable@ as
that's the documented way AND you will get proper integration into the
process (i.e. emails when things fail to apply.)  If you don't cc:
stable@ but do just use "Fixes:" and haven't told us otherwise (see my
previous email here), then us stable maintainers just have to guess and
try to apply "Fixes:" commits as they obviously are fixing real problems
that people have and report and want resolved.

thanks,

greg k-h

  parent reply	other threads:[~2024-07-15 15:10 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-14 12:31 Proposal: Enhancing Commit Tagging for Stable Kernel Branches Sasha Levin
2024-07-14 13:35 ` James Bottomley
2024-07-14 15:35   ` Andrew Lunn
2024-07-14 16:34     ` James Bottomley
2024-07-14 18:38   ` Sasha Levin
2024-07-14 19:20     ` James Bottomley
2024-07-14 20:18       ` Sasha Levin
2024-07-15 18:00         ` Theodore Ts'o
2024-07-15 18:07           ` Mark Brown
2024-07-15 19:06           ` Dan Carpenter
2024-07-15 19:23             ` Steven Rostedt
2024-07-15 19:24             ` James Bottomley
2024-07-15 19:28               ` Steven Rostedt
2024-07-15 19:30                 ` James Bottomley
2024-07-15 19:39               ` Dan Carpenter
2024-07-16  6:30                 ` Greg KH
2024-07-15 20:25               ` Mauro Carvalho Chehab
2024-07-15 20:47             ` Dmitry Torokhov
2024-07-16  6:28               ` Greg KH
2024-07-16 12:20                 ` Takashi Iwai
2024-07-17 22:05                   ` Dan Carpenter
2024-07-18  7:34                     ` Takashi Iwai
2024-07-18 14:48                       ` Dan Carpenter
2024-07-18 14:56                         ` James Bottomley
2024-07-18 16:36                           ` Dan Carpenter
2024-07-19  0:49                             ` NeilBrown
2024-07-19  1:35                               ` Dan Carpenter
2024-07-19 11:55                                 ` Vegard Nossum
2024-07-23 14:14                                   ` Jiri Kosina
2024-07-16 14:51       ` Jason Gunthorpe
2024-07-16 19:38         ` Dan Carpenter
2024-07-15  6:15     ` Mauro Carvalho Chehab
2024-07-14 17:07 ` Linus Torvalds
2024-07-14 18:47   ` Sasha Levin
2024-07-14 19:27     ` Linus Torvalds
2024-07-14 20:27       ` Sasha Levin
2024-07-14 23:05         ` James Bottomley
2024-07-14 23:09           ` Linus Torvalds
2024-07-15  8:02             ` Greg KH
2024-07-15  8:53               ` Mauro Carvalho Chehab
2024-07-15 12:48               ` Mimi Zohar
2024-07-15 12:52                 ` Mimi Zohar
2024-07-15 14:34                   ` Alexandre Belloni
2024-07-15 14:40                     ` Greg KH
2024-07-15 15:00                       ` Jonathan Corbet
2024-07-15 15:07                         ` James Bottomley
2024-07-15 15:19                           ` Sasha Levin
2024-07-15 15:31                             ` James Bottomley
2024-07-15 15:42                             ` Dan Carpenter
2024-07-15 15:10                         ` Greg KH [this message]
2024-07-15 17:45                           ` Mauro Carvalho Chehab
2024-07-15 18:04                       ` Mark Brown
2024-07-15 20:51                         ` Dmitry Torokhov
2024-07-16  6:25                         ` Greg KH
2024-07-16 15:00                           ` Mark Brown
2024-07-14 23:29           ` NeilBrown
2024-07-14 23:29         ` Steven Rostedt

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=2024071537-unskilled-boney-2fb6@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=corbet@lwn.net \
    --cc=ksummit@lists.linux.dev \
    --cc=sashal@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=zohar@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.