linux-kernel - Re: 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]

Date:	Mon, 15 Jul 2013 16:20:37 -0400
From:	Jason Cooper <jason@...edaemon.net>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	ksummit-2013-discuss@...ts.linuxfoundation.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: KS Topic request: Handling the Stable kernel, let's dump the
 cc: stable tag

On Mon, Jul 15, 2013 at 11:27:56PM +0400, James Bottomley wrote:
...
> The solution, to me, looks simple:  Let's co-opt a process we already
> know how to do: mailing list review and tree handling.  So the proposal
> is simple:
> 
>      1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
>         reviewed patch to stable
>      2. All patches to stable should follow current review rules: They
>         should go to the mailing list the original patch was sent to
>         once the original is upstream as a request for stable.
>      3. Following debate on the list, the original maintainer would be
>         responsible for collecting the patches (including the upstream
>         commit) adjudicating on them and passing them on to stable after
>         list review (either by git tree pull or email to stable@).
> 
> I contend this raises the bar for adding patches to stable much higher,
> which seems to be needed, and adds a review stage which involves all the
> original reviewers.

If I may expand on the 'tree-handling' with an idea:

When I'm collecting up patches for mvebu, the first thing I do is
classify the patch as a fix for the current -rc cycle, or for next.  It
would be very easy to maintain a stable branch "ahead of" fixes.  More
accurately, one for each stable version.  eg:

stable-3.2
stable-3.4
stable-3.9
stable-3.10
fixes
cleanup (or next)
...

Each branch would need to be based on a commit in the mainline tree, eg
stable-3.2 would be based on v3.2, not v3.2.48.

Anything I suspect is stable material goes in the earliest relevant
stable branch, and I send an email series to the linux-stable list.
Discussion ensues, maybe I remove one or two patches from the stable
branch and only put them in fixes (so, for -rcX), and send the PR.  The
stable team can then merge the PR, once they see the commit in mainline.

The big advantage of this proposal is that the patch would have the same
commit id in both trees.  'git branch -a --contains <commit-ish>' would
work.

The main problem with this is that maintainers would need to do the
legwork themselves to figure out how far back a patch is relevant for.
Maybe this would be a feature? ;-)

Unfortunately, since most of the time there's just a single patch, I'm
not sure the cost of the merge commits is worth the benefit of having
the same commit id in stable and mainline.

thx,

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