linux-kernel - RFD: linux-oven to help with cross-tree collateral evolutions

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>] [day] [month] [year] [list]

Message-ID: <20150619231255.GC7487@garbanzo.do-not-panic.com>
Date:	Fri, 19 Jun 2015 16:12:55 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	linux-kernel@...r.kernel.org
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	gregkh@...uxfoundation.org, bp@...e.de, luto@...capital.net,
	julia.lawall@...6.fr, Ingo Molnar <mingo@...e.hu>,
	Michael Ellerman <mpe@...erman.id.au>,
	Stephen Rothwell <sfr@...b.auug.org.au>, mcgrof@...e.com
Subject: RFD: linux-oven to help with cross-tree collateral evolutions

When working on collateral evolutions often times by definition
we end up having to go and transform existing drivers to new APIs
tree wide. You have a few options when this happens:

0) *If* you're lucky your collateral evolution is very specific to
   a subsystem and you get to only work with one maintainer.

   Otherwise:

1) You get approval from a subsystem maintainer for their respective
   driver changes to go in through the tree you are introducing the
   new symbols you are adding or symbols you are changing.

2) You sit tight and wait for the symbols to go in through one
   release, and on the next next release you submit the changes
   for the drivers.

3) You wait towards the end of the merge window and finally
   send directly to a subsystem maintainer, who then sends
   to Linus.

As noted, 0) is a breeze and is pretty straight forward.

The problem with 1) is you need coordination with maintainers and
while this can be a smooth process it typically is more an irritation
for the maintainers involved, its more work on other maintainers, and
you should not be surprised if some folks get irritated. Understandably
there can be a limit to what one maintainer should accept to go in through
their tree just for cross-tree collateral evolution effects.

The problem with 2) is the obvious lag behind making your changes
take effect through 2 full releases, as per our latest stats [0]
we get a release every 2.5 months, so on average cross-tree collateral
evolutions with strategy 2) means you'd have to wait ~5 months in order
to see your changes in the wild, with a reasonable added *minimum* delay
of say... about 1 month for review that's realistically more like a
full half year to wait. That's a lot of time... that's pretty slow.

3) still requires going through a subsystem maintainer, that seems
rather slow, specially if the patches are already acked and all
you were doing was waiting for the merge window. That can only
delay the merge window a bit.

I think we can do better and I think we can do with this much less irratation
for maintainers. What if we had a linux-oven tree based on linux-next
which queues up all pending-but-already-acked cross-tree collateral evolution
patches? This tree can be rebased daily on linux-next using:

  git rebase --onto next/master'

for example, and this maintainer can then send these cross-tree
collateral evolution changes to Linus towards the end of the merge
window.

Thoughts?

[0] http://phb-crystal-ball.org/

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/