Re: [Ksummit-discuss] Kernel Summit Agenda -- 2nd draft

[Josh Triplett <josh@joshtriplett.org>]

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 <tytso@mit.edu> 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