Message-ID: <1373925699.17876.218.camel@gandalf.local.home>
Date:	Mon, 15 Jul 2013 18:01:39 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Greg KH <greg@...ah.com>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	ksummit-2013-discuss@...ts.linuxfoundation.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable
 kernel, let's dump the cc: stable tag

On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:

> I don't like this at all, just for the simple reason that it will push
> the majority of the work of stable kernel development on to the
> subsystem maintainers, who have enough work to do as it is.
> 
> Stable tree stuff should cause almost _no_ extra burden on the kernel
> developers, because it is something that I, and a few other people, have
> agreed to do with our time.  It has taken me 8 _years_ to finally get
> maintainers to agree to mark stuff for the stable tree, and fine-tune a
> development process that makes it easy for us to do this backport work.

Although, since those 8 years, the stable tree has proven its
importance.

Is a extra "ack" also too much to ask?

> 
> I _want_ the exact same commit that is in Linus's tree for the backport
> because if I have to rely on a maintainer to do the backport and resend
> it, I _know_ it will usually be a changed patch, and the git commit id
> will be lost.

This is a good point and a valid concern.


> 
> I know this because it happens today.  I get patches from maintainers
> that are radically changed from what is in Linus's tree without any
> justification for why that is.  That's not ok.
> 
> Let me work with the distros on the issues they have raised.  So far I
> have the following issues they have complained about:
>   - patches that shouldn't be there because they don't really do
>     anything.
>   - patches that aren't obvious why they are there.
> 
> The first one I am going to be pushing back on, and have already, much
> to the dismay of some subsystem maintainers.
> 
> The second one is almost always due to security issues that were unknown
> to the distro.  The announcement of security problems to the distros has
> now been addressed, and since that has changed, I haven't heard any
> problems about this.
> 
> Have I missed anything else that the distros are objecting to?  The
> "smaller" distros (i.e. ones without lots of kernel developers) have
> been giving me nothing but _thanks_ and appreciation with the way that
> I've been sucking in all of the different fixes.  Do we want to mess

This is proof of how important stable has been.

> with a process that is really working out well for them, and only causes
> annoyance at times by the larger ones?


The big problem with the above is that the process depends highly on
this guy named "Greg".

If "Greg" gets tired of doing this, or gets sick, or "see other KS topic
about mortality of maintainers", then the entire process fails.

OK, you are not the only one that does the stable release. There's Ben
and Luis doing it as well, and various others. But there seems to be a
bit of an issue here. How much should go into stable? Who really
decides?

How important is the stable releases? Are maintainers willing to do a
little more work now to make sure their subsystems work fine in older
kernels? This isn't the same stable as it was 8 years ago.

I guess this is a great topic for KS, as it seems to be going all over
the place via email, and would probably be much better sorted out face
to face.

-- Steve



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists