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: <20130715195505.GE10157@1wt.eu>
Date:	Mon, 15 Jul 2013 21:55:05 +0200
From:	Willy Tarreau <w@....eu>
To:	Steven Rostedt <rostedt@...dmis.org>
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

Hi Steven,

On Mon, Jul 15, 2013 at 03:45:17PM -0400, Steven Rostedt wrote:
> How about this as a proposal.
> 
> Keep the Cc: stable@ tag as it is today.
> 
> Have Greg, or whoever, change his script to not take commits marked for
> stable, but instead, forward the commit to the maintainer. Or as it
> already does today, to everyone on the Cc, and -by: tags. Change the
> script from being "stable review" to say "Look to see what you want, and
> resend what is needed for stable".
> 
> Then the maintainer needs to look at all the patches that were marked
> for stable, and resend them to Greg saying which ones should go into
> stable.
> 
> This has a few advantages.
> 
> 1) lets anyone still mark their patch as a stable fix, even if at the
> end isn't.
> 
> 2) Some commits can be marked for stable, for those that want to read
> git logs, but not send to stable (the Fixes: tag as described in another
> thread).
> 
> 2) Makes the stable decision go where it belongs. To the maintainer of
> that system. It lets the maintainer think twice about what goes to
> stable or not.
> 
> 3) gives a little more time if needed, to let stable commits stir in
> mainline. If its a security fix, the maintainer should be on the ball to
> get in to stable, and not just let Greg worry about it.
> 
> 4) Probably the most important. It should unload most of the work off of
> Greg, and push it more on the maintainers. Greg would just need to make
> sure the patch goes to the right person (probably not an issue, as it is
> most likely on the Signed off by line). Then the maintainers could
> review the commits that should go to stable, and if needed, not send
> them. They could also send commits that were not marked for stable, as
> long as they are already in mainline.
> 
> Also, we could mandate that the maintainers do the backports too.

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.

Regards,
Willy

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