From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 26 Oct 2015 15:28:21 +0900 From: Josh Triplett To: "Luis R. Rodriguez" Message-ID: <20151026062820.GA1021@x> References: <20151020220328.GA21941@thunk.org> <20151021145626.GD2165@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: , On Sun, Oct 25, 2015 at 10:56:49PM -0700, Luis R. Rodriguez wrote: > 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 Hear hear; I'm extremely interested in a solution to this problem, and I'd like to participate in this discussion. Attempting to make a kernel-wide change that touches multiple subsystems typically either requires extensive coordination between subsystem maintainers, or more commonly, slowly filtering changes in over several kernel releases and maintaining compatibility layers. - Josh Triplett