From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: ebiederm@xmission.com (Eric W. Biederman) To: "Luis R. Rodriguez" References: <20151020220328.GA21941@thunk.org> <20151021145626.GD2165@thunk.org> Date: Mon, 26 Oct 2015 01:12:27 -0500 In-Reply-To: (Luis R. Rodriguez's message of "Sun, 25 Oct 2015 22:56:49 -0700") Message-ID: <8737wy17lg.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain Cc: ksummit-discuss@lists.linux-foundation.org Subject: Re: [Ksummit-discuss] Kernel Summit Agenda -- 2nd draft List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , "Luis R. Rodriguez" writes: > On Wed, Oct 21, 2015 at 7:56 AM, Theodore Ts'o wrote: >> On Tue, Oct 20, 2015 at 07:36:31PM -0700, Olof Johansson wrote: >>> > 3:30 - Kernel Development Process (Is Linus happy?) >>> >>> We usually check in with Stephen Rothwell as well to see how happy or >>> miserable he is, probably in the same slot though? >> >> Yep. Given the recent "commits in -rc1 not in next" statistic have >> been consistently getting better for the last 3 or 4 releases, I'm >> assuming/hoping this means that on the whole both Linus and Stephen >> are probably pretty happy with how things are going on the development >> process front. >> >> But if Linus, Stephen, or anyone else for that matter has thoughts or >> suggestions about how we can do things better, this is the slot for >> it. > > I was reluctant to bring this up, but today's presentation by Jonathan > Corbet, prompts me to throw one possible optimization out there. This > issue does not relate to Linus or Stephen directly but rather > developers who need to work with the implications of our subsystem > maintainer model. Although our pace is great, one area where I think > is a bit troublesome and can only get more troublesome with more time > is the impact of *cross-tree collateral evolutions* of code as code > size grows. I say cross-tree as if you're working with only one > subsystem this issues does not exist. The type of cross-tree > collateral evolutions could be simple library changes, or just > renames, or more complex things. They tend to be an issue because of > the large size of the kernel but not because these cross-tree > collateral evolutions are hard to to implement, given that we now have > tools to help us with this, but rather simple coordination between > different tree maintainers, the impact of this on a large queue set of > pending changes in different subsystem maintainer trees, and the long > delay which is now needed over all the different subsystem maintainer > acks needed for the cross-tree collateral evolution. Since the kernel > is *so big* things that can help with this might be increasing the > pace of a release, that has its own drawbacks though... Another > possibility is to have a dedicated tree for cross-tree collateral > evolutions. I proposed this a while ago [0] through a linux-oven. I go > into the issues on the thread, so instead of copy+pasting that here > please refer to that for more details. The only addendum to that > e-mail I can add is that for approach 3) (merge all changes via one > maintainer) mentioned there is that one can merge things actually > *either* at the end of the merge window or a the beginning and the > choice is up to the maintainer who decides to take things in if the > choice for the cross-tree collateral evolutions is to go through *one* > maintainer. > > Reason this probably has not come up as an issue of concern to Linus > or other maintainers is that its the developer's job to do all the > work to get the cross-tree collateral evolutions in. The maintainers > are only involved when doing coordination with other maintainers, and > Linus would hopefully and ideally be removed or shielded from issues > when issues creep up on these, mostly thanks these days to linux-next. > Invite you to seriously evaluate the timing implications on the e-mail > referenced so you get an idea of why although our pace is fast, for > cross-tree collateral evolutions this can become an issue. Specially > if your cross-tree collateral evolutions are requirements for a new > feature or perhaps who knows, maybe a new driver. > > [0] > http://lkml.kernel.org/r/20150619231255.GC7487@garbanzo.do-not-panic.com I think it really depends on what is going on. If it is complex and interesting work you really do need to go through the experts of a subsystem and get their buy off, so you have maintainable code. If you can reach accord quickly it is probably easiest to have a common tree (based on something like -rc1) that both subsystem maintainers can merge. For tree wide changes where only minimal approval is needed from maintainers simply running a tree for the conversion is a common pattern that works well. When you propose a tree that gets rebased daily I think you are going in the wrong direction. There are some many varieties of dependencies and so many different varieties of needed code review that I really don't think it makes sense to try for a one size fits all solution (short of running your own tree for the change). Although to be honest I have done something like that this cycle and all of the trees fed into net-next and the maintainers were responsive so despite having to feed changes through 3 different maintainers I had no significant challenges. So for me. Been there, done that, and I do not see the problem you are trying to fix. Eric