linux-kernel - Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1373921779.17876.200.camel@gandalf.local.home>
Date:	Mon, 15 Jul 2013 16:56:19 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Willy Tarreau <w@....eu>
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 21:55 +0200, Willy Tarreau wrote:

> I disagree with your proposal. All these points are already covered by
> the stable review and the early notification that the greg-bot does when
> the patch is included in the queue. If submitters/maintainers do not read
> these e-mails sent to them about changes going to happen in the subsystems
> they're responsible for, having them resend the patches will only punish
> the honnest ones. The other ones will simply reply without doing anything
> else. In the end, we get more work to get fixes merged so less efficiency.
> 
> I tend to think the merge should be slightly less automatic or at least
> add some delay (post release for late submissions), but what I'm worried
> about is that adding exceptions to the workflow will mean more work for
> Greg, so we should be careful about this, as we have a single one and we
> don't want to burn him out.
> 

I'm temporarily maintaining a 3.6 stable release (can't wait till I
don't have to do that anymore). And I cheat. I use the trees that Greg
uses, and I still spend days getting it ready.

I think the current method does not scale. It's only been doing so well
only because Greg has been putting a lot of time and effort into it. But
I still think the process is broken.

Do I think this will add more work to the maintainer? Yes, definitely!
But we have hundreds of maintainers, and only one Greg. Where do you
think we should be adding the work too?

In another KS topic, we talked about backup maintainers. This could be
the job of #2.

Yes, there's already a automatic response, but who really looks a those.
I know I'm guilty of seeing that and saying to myself "oh good, Greg
added that patch" and not actually review it. This process may force me
to look at it better.

It may not be efficient for maintainers, but as maintainers we should
spend a bit more time on stable releases. If you do that up front before
marking commits with the stable tag, then just setup a mail filter that
simply forwards the email to the second address that Greg will take. If
you abuse that, then Greg can get nasty with you ;-)

-- 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/