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

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

[Theodore Ts'o]

Hi all,

Here's the next revision of the Kernel Summit draft.  Please take a
look at the assignment of technical topics to slots.  If you see
potential conflicts ("I really want to attend topics X and X+10"),
please make a comment on the e-mail thread.  We may not be able to
accomodate all schedule requests, but I'll do my best.

The TBD slots are available for scheduling in an "unconference" style.
To that end, we will have lightning talks at 9am, so if you want to
plug a last-minute topic that get formally scheduled sometime on
Tuesday, or where you want to find like-minded people for a hallway
discussion, we'll have time for that there.  If you are interested in
giving a lightning talk Tuesday morning at 9am, I'd appreciate it if
you could drop me a note by Monday morning.


Cheers,

					- Ted



			  Kernel Summit Agenda
			   October 26-28, 2015
				 DRAFT

Attendee list: https://sites.google.com/site/ksummit2015/attendee-list

Web Version Agenda: https://sites.google.com/site/ksummit2015/agenda	

* Monday: Media Workshop and break out sessions (alongside Korea Linux Forum)
* Tuesday: Dual-track technical sessions
* Wednesday: Invite-only core attendees' plenary sessions

Dual-Track Technical sessions (Oct. 27th)
=========================================

9:00    - Welcome and agenda bashing / Lightning Talks
9:30	- Topic 1                   | Topic 11
10:00   - Topic 2                   | Topic 12
10:30   - Break
11:00	- Topic 3                   | Topic 13
11:30   - Topic 4                   | Topic 14
12:00   - Topic 5                   | Topic 15
12:30   - Lunch
1:30    - Topic 6                   | Topic 16
2:00    - Topic 7                   | Topic 17
2:30    - Break
3:00    - Topic 8                   | Topic 18
3:30    - Topic 9                   | Topic 19
4:00    - Topic 10                  | Topic 20
4:30    - Break
5:00    - Kernel Summit Tech Day -- What went well, what can we do better? 
5:45    - Group Photograph (for all kernel summit attendees)
6:00    - Dinner

Tech topics
===========

1. Mainline kernel on a cellphone (Rob Herring)
2. Semantics of MMIO mapping attributes across archs (Benjamin Herrenschmidt)
3. System-wide interface to specify the level of PM tuning (Rafael J. Wysocki)
4. Giving freezer well-defined semantics (Jiri Kosina)
5. TBD
6. Benchmarking And Performance Trends (Chris Mason)
7. Mainlining PREEMPT_RT (Steven Rostedt)
8. Improving Kernel Security  (James Morris / Kees Cook)
9. Developer Workflow Security (Panel)
10. Firmware signing (David Howells)

11. TBD
12. The Next Generation of the Media Controller (Mauro Carvalho Chehab)
13. Kernel support for compute-offload devices (Joerg Roedel)
14. TBD
15. IRQ affinity (Christoph Hellwig)
16. TBD
17. ZONE_DEVICE and Persistent Memory (Dan Williams)
18. TBD
19. TBD
20. Context tracking / nohz / RCU state (Andy Lutomirski / Paul McKenney)

Core Day (Oct. 28th)
====================

9:00    - Welcome and agenda bashing
9:30	- Testing (Masahami, Shuah)
10:00   - Kernel Security - Readout and further discussion
10:30   - Break
11:00	- Recruitment; Outreach Programmes (Greg K-H)
11:30   - Lightweight per-cpu locks / restartable sequences (Andy Lutomirski) (*)
12:00   - Lightning Talks
12:30   - Lunch
1:30    - Issues with stable process (Sasha Levin)
2:00    - TBD
2:30    - Break
3:00    - Documentation (Jon Corbet)
3:30    - Kernel Development Process (Is Linus happy?)
4:00    - TBD
4:30    - Break
5:00    - Kernel Summit Core Day -- What went well, what can we do better? 
5:45    - Group Photograph (for core day attendees)
6:00    - Dinner

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

[Jason Cooper]

Ted, all,

On Tue, Oct 20, 2015 at 06:03:28PM -0400, Theodore Ts'o wrote:
...
> Attendee list: https://sites.google.com/site/ksummit2015/attendee-list

Unfortunately, I will not be able to attend.  I had a late schedule
change (well, a month out).  I de-registered and emailed the relevant
people offlist at the time.  I hope someone was able to take my slot...

> Tech topics
> ===========
> 
> 1. Mainline kernel on a cellphone (Rob Herring)
> 2. Semantics of MMIO mapping attributes across archs (Benjamin Herrenschmidt)
> 3. System-wide interface to specify the level of PM tuning (Rafael J. Wysocki)
> 4. Giving freezer well-defined semantics (Jiri Kosina)
> 5. TBD
> 6. Benchmarking And Performance Trends (Chris Mason)
> 7. Mainlining PREEMPT_RT (Steven Rostedt)
> 8. Improving Kernel Security  (James Morris / Kees Cook)
> 9. Developer Workflow Security (Panel)

Which means, I won't be able to participate in my own proposed topic. :(

Please let me know how it goes.  Whoever is taking lead on this, please
get in touch with me if you have any questions about what I was
thinking.

> 10. Firmware signing (David Howells)
> 
> 11. TBD
> 12. The Next Generation of the Media Controller (Mauro Carvalho Chehab)
> 13. Kernel support for compute-offload devices (Joerg Roedel)
> 14. TBD
> 15. IRQ affinity (Christoph Hellwig)
> 16. TBD
> 17. ZONE_DEVICE and Persistent Memory (Dan Williams)
> 18. TBD
> 19. TBD
> 20. Context tracking / nohz / RCU state (Andy Lutomirski / Paul McKenney)
> 
> Core Day (Oct. 28th)
> ====================
> 
> 9:00    - Welcome and agenda bashing
> 9:30	- Testing (Masahami, Shuah)
> 10:00   - Kernel Security - Readout and further discussion

I think this is the output of "Developer Workflow Security" as well as
"Improving Kernel Security".

thx,

Jason.

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

[Olof Johansson]

Hi,

On Tue, Oct 20, 2015 at 3:03 PM, Theodore Ts'o <tytso@mit.edu> wrote:

> Core Day (Oct. 28th)
> ====================
>
> 9:00    - Welcome and agenda bashing
> 9:30    - Testing (Masahami, Shuah)
> 10:00   - Kernel Security - Readout and further discussion
> 10:30   - Break
> 11:00   - Recruitment; Outreach Programmes (Greg K-H)
> 11:30   - Lightweight per-cpu locks / restartable sequences (Andy Lutomirski) (*)
> 12:00   - Lightning Talks
> 12:30   - Lunch
> 1:30    - Issues with stable process (Sasha Levin)
> 2:00    - TBD
> 2:30    - Break
> 3:00    - Documentation (Jon Corbet)
> 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?


-Olof

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

[Theodore Ts'o]

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.

						- Ted

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

[Guenter Roeck]

On 10/21/2015 07: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.
>
Mainline is getting pretty good. Build and runtime failures introduced
in commit windows tend to get fixed around rc3-ish (as measured with
"my builds and qemu tests all pass"), which is much better than it used to be.

Number of build and runtime breakages in -next is a bit high, and fixes are
sometimes slow to roll in. At least in part this is because those responsible
for breakages are not informed, but I have also seen problems which were
known for weeks to propagate into mainline before they got fixed, even if
the culprit was informed. This could use some improvement, though I am not
really sure how we could get there. Make more noise ?

Guenter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Wed, Oct 21, 2015 at 08:20:54AM -0700, Guenter Roeck wrote:

> Number of build and runtime breakages in -next is a bit high, and fixes are
> sometimes slow to roll in. At least in part this is because those responsible
> for breakages are not informed, but I have also seen problems which were
> known for weeks to propagate into mainline before they got fixed, even if
> the culprit was informed. This could use some improvement, though I am not
> really sure how we could get there. Make more noise ?

Noise is probably a large part of it, having a human following up about
issues seems to help a lot.

I've seen some active resistance to pushing fixes to mainline without
lengthy soaks in -next in a very rules based fashion which isn't super
awesome when it takes out other testing due to the breakage.  As the
test coverage improves this is going to be getting to be more and more
of an issue as failures to build or boot will cause gaps in other
testing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Guenter Roeck]

On 10/21/2015 09:09 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015 at 08:20:54AM -0700, Guenter Roeck wrote:
>
>> Number of build and runtime breakages in -next is a bit high, and fixes are
>> sometimes slow to roll in. At least in part this is because those responsible
>> for breakages are not informed, but I have also seen problems which were
>> known for weeks to propagate into mainline before they got fixed, even if
>> the culprit was informed. This could use some improvement, though I am not
>> really sure how we could get there. Make more noise ?
>
> Noise is probably a large part of it, having a human following up about
> issues seems to help a lot.
>

Sure, and I do that if I can find the time. In my experience, submitting
patches to fix observed problems turns out to be the best approach.
Even (or especially) if plain wrong or less than perfect, patches are
almost guaranteed to trigger a response.

Doing this is just very time consuming, and time is always short.

Also, while beneficial for the system as a whole, I am not sure if it is
beneficial for the submitter. Touching multiple subsystems almost
guarantees for the submitter to get something wrong, either because
of unfamiliarity with the code or because of maintainer preferences.

Does submitting patches all over the place benefit or hurt my reputation
with other maintainers, given that the percentage of rejected patches
is quite high ? I don't know, and I don't really care that much since my
ultimate goal is to get problems fixed, not to get my patches accepted.
However, for others it may play a role when deciding if or if not to
spend the time, track down a problem, and submit a patch for it.

> I've seen some active resistance to pushing fixes to mainline without
> lengthy soaks in -next in a very rules based fashion which isn't super
> awesome when it takes out other testing due to the breakage.  As the
> test coverage improves this is going to be getting to be more and more
> of an issue as failures to build or boot will cause gaps in other
> testing.
>
For fixes ? I don't recall seeing that reaction, at least not to patches
I have been involved in. Unless in very special cases, it doesn't seem
to make much sense to me to require bug fixes to soak in -next.

Guenter

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

[Luck, Tony]

> is quite high ? I don't know, and I don't really care that much since my
> ultimate goal is to get problems fixed, not to get my patches accepted.

Should we include these words of wisdom in Documentation/SubmittingPatches?

-Tony

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Wed, Oct 21, 2015 at 09:37:04AM -0700, Guenter Roeck wrote:

> Does submitting patches all over the place benefit or hurt my reputation
> with other maintainers, given that the percentage of rejected patches
> is quite high ? I don't know, and I don't really care that much since my
> ultimate goal is to get problems fixed, not to get my patches accepted.
> However, for others it may play a role when deciding if or if not to
> spend the time, track down a problem, and submit a patch for it.

Yeah, I mostly just report problems (partly because it's just less time
consuming).  On the reviewer side fixes like that only get to be an
issue when submitters ignore feedback and keep on sending the same stuff
even after discussion as to why other approaches are better.

> >I've seen some active resistance to pushing fixes to mainline without
> >lengthy soaks in -next in a very rules based fashion which isn't super
> >awesome when it takes out other testing due to the breakage.  As the
> >test coverage improves this is going to be getting to be more and more
> >of an issue as failures to build or boot will cause gaps in other
> >testing.

> For fixes ? I don't recall seeing that reaction, at least not to patches
> I have been involved in. Unless in very special cases, it doesn't seem
> to make much sense to me to require bug fixes to soak in -next.

It's definitely not the norm but I have encountered it.  Obviously
indivudal cases will differ, sometimes there will be value in exposure
in -next (eg, if it's likely to get validation from the boot farms),
it's a question of what the issue is, what the coverage is and what the
risks of the fix are.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Jonathan Corbet]

On Wed, 21 Oct 2015 17:24:19 +0000
"Luck, Tony" <tony.luck@intel.com> wrote:

> > is quite high ? I don't know, and I don't really care that much since my
> > ultimate goal is to get problems fixed, not to get my patches accepted.  
> 
> Should we include these words of wisdom in Documentation/SubmittingPatches?

The docs maintainer will happily accept patches...:)

FWIW, something to this effect can be found at the end of
Documentation/development-process/6.Followthrough, but I suspect few
people get that far.

jon

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

[Theodore Ts'o]

On Wed, Oct 21, 2015 at 09:37:04AM -0700, Guenter Roeck wrote:
> 
> Sure, and I do that if I can find the time. In my experience, submitting
> patches to fix observed problems turns out to be the best approach.
> Even (or especially) if plain wrong or less than perfect, patches are
> almost guaranteed to trigger a response.
> 
> Doing this is just very time consuming, and time is always short.
> 
> Also, while beneficial for the system as a whole, I am not sure if it is
> beneficial for the submitter. Touching multiple subsystems almost
> guarantees for the submitter to get something wrong, either because
> of unfamiliarity with the code or because of maintainer preferences.

Speaking as a maintainer, if you can report a regression, I will
definitely take it seriously, with or without a patch.  What's
actually most useful is a git bisection, or failing that, a report of
the last kernel version where things worked, and a reliable repro.
Not that I would turn down a patch, of course, but being able to point
the finger at the guilty patch is often the most useful thing a bug
reporter can contribute.

Cheers,

					- Ted

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

[Alexandre Belloni]

On 22/10/2015 at 11:25:02 -0400, Theodore Ts'o wrote :
> On Wed, Oct 21, 2015 at 09:37:04AM -0700, Guenter Roeck wrote:
> > 
> > Sure, and I do that if I can find the time. In my experience, submitting
> > patches to fix observed problems turns out to be the best approach.
> > Even (or especially) if plain wrong or less than perfect, patches are
> > almost guaranteed to trigger a response.
> > 
> > Doing this is just very time consuming, and time is always short.
> > 
> > Also, while beneficial for the system as a whole, I am not sure if it is
> > beneficial for the submitter. Touching multiple subsystems almost
> > guarantees for the submitter to get something wrong, either because
> > of unfamiliarity with the code or because of maintainer preferences.
> 
> Speaking as a maintainer, if you can report a regression, I will
> definitely take it seriously, with or without a patch.  What's
> actually most useful is a git bisection, or failing that, a report of
> the last kernel version where things worked, and a reliable repro.
> Not that I would turn down a patch, of course, but being able to point
> the finger at the guilty patch is often the most useful thing a bug
> reporter can contribute.
> 

One corner case that can happen is that a maintainer takes a patch for
another subsystem (because it also touches his subsystem or depends on
it or whatever). If this patch introduces a regression, it is sometimes
difficult to get a fix merged because it is not obvious that the
maintainer that took the offending patch has to take it and the
subsystem maintainer can't take the fix until -rc1.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Rafael J. Wysocki]

On Thursday, October 22, 2015 10:01:10 PM Alexandre Belloni wrote:
> On 22/10/2015 at 11:25:02 -0400, Theodore Ts'o wrote :
> > On Wed, Oct 21, 2015 at 09:37:04AM -0700, Guenter Roeck wrote:
> > > 
> > > Sure, and I do that if I can find the time. In my experience, submitting
> > > patches to fix observed problems turns out to be the best approach.
> > > Even (or especially) if plain wrong or less than perfect, patches are
> > > almost guaranteed to trigger a response.
> > > 
> > > Doing this is just very time consuming, and time is always short.
> > > 
> > > Also, while beneficial for the system as a whole, I am not sure if it is
> > > beneficial for the submitter. Touching multiple subsystems almost
> > > guarantees for the submitter to get something wrong, either because
> > > of unfamiliarity with the code or because of maintainer preferences.
> > 
> > Speaking as a maintainer, if you can report a regression, I will
> > definitely take it seriously, with or without a patch.  What's
> > actually most useful is a git bisection, or failing that, a report of
> > the last kernel version where things worked, and a reliable repro.
> > Not that I would turn down a patch, of course, but being able to point
> > the finger at the guilty patch is often the most useful thing a bug
> > reporter can contribute.
> > 
> 
> One corner case that can happen is that a maintainer takes a patch for
> another subsystem (because it also touches his subsystem or depends on
> it or whatever). If this patch introduces a regression, it is sometimes
> difficult to get a fix merged because it is not obvious that the
> maintainer that took the offending patch has to take it and the
> subsystem maintainer can't take the fix until -rc1.

Quite arguably, whoever took a patch is also responsible for handling any
fallout from it as a rule.

Thanks,
Rafael

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

[Luis R. Rodriguez]

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

  Luis

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

[Eric W. Biederman]

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:

> 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

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

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

[Josh Triplett]

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