[Ksummit-discuss] "Maintainer summit" invitation discussion

[Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

The kernel summit is apparently in October, and I promised last year
to at least get the ball rolling with the people *I* would like to
see.

I even subscribed to this list, though I promised myself I wouldn't
get involved in any other discussion.

I've actually churned the numbers several ways, none of which really
make me convinced that metric matters much. Looking at actual
developers (actually, I generally just did "committers" rather than
actual "authors"), you can certainly just do it by number of commits
(or sizes of commits, or numbers of files touched), all of which I
tried, and all of which actually got fairly similar "top 20" lists.

And none of those "top 20" lists looked precisely wrong, but they
didn't look precisely right either.

So being in the quiet "late rc" period, I decided to try to just do
statistics over who I pull from, and how much I pull instead. Which is
much closer to that "maintainer summit" I think I want. And the end
result actually looks not unreasonable when I do that. I ended up
approximating the sorting by "cumulative files changed" (ie just
counting number of files changed for each pull request I do: so the
same file will count N times if it shows up in N pull requests).

Like all the other metrics I tried, it does end up skewing one way or
the other: people who touch a lot of files in trivial ways get counted
more, but looking at the list I don't see anything really odd
anywhere. In particular, with that metric I get the obvious two top
maintainers being David Miller and Greg KH - which would be pretty
much a requirement for any sane maintainership counting algorithm. The
tip and arm maintainers also show up, although they obviously get
diluted by spreading out their work.

You can see the "top 10" list by just looking at the Cc of this email.
That one looks sane too, and contains the main architectures (x86,
arm, powerpc) and the biggest driver subsystems (drm, media, sound and
rdma).  And Andrew Morton.

None of the filesystem people show up in the top 10, although Al does
show up at spot 11, and individual filesystems show up lower down the
list (mainly just xfs and ext4).

What I _would_ like to see is those top maintainers suggest
"submaintainer" names. Particularly Davem, since he doesn't tend to
want to come to the kernel summit, and being at the top of the list
that's a kind of big gaping hole. I guess we haven't had all that many
_problems_ within networking, but if we talk maintainership issues,
it's certainly a bit odd if it's entirely lacking. We have both core
networking and network drivers that both fall under "davem" as far as
my pull statistics go.

I'm appending the "top 50" list in its entirely for people to look at
- the numbers are the "cumulative files changed in pull requests
_directly_ to me over the last 12 months". I'm not saying these people
all make sense: I think we should also take other issues into account,
and in particular rather than just a fairly straightforward "size of
subsystem" it should be about maintenance burden size too.

So drm and rdma both show up fairly high on both of those lists, I
think, and thus should be part of any maintainership discussion - but
maybe some other subsystems just aren't enough of a maintenance
headache to worry about?

So the other way to split it up is by "maintenance area", ie we have

 - architectures

   Pretty much covered by x86, arm, powerpc, and those architectures
should talk about who within the group would attend.

 - drivers

   Obviously we have Greg overall, with drm and rdma because of issues.

   An example here is that Christoph doesn't show up because I don't
generally pull from him, but he's been all over and often crosses
multiple driver subsystems, and has been involved in rdma too, so I'd
add him just for that.

   Some driver subsystems may be huge (eg media and sound), but I
don't know if they have issues. Mauro/Takashi?

 - filesystems

   Al, XSF and ext4 stand out by size (XFS is mostly Dave Chinner due
to me going by past year, but is obviously Darrick Wong right now).

 - core stuff.

   We've got Andrew, and I'd add Tejun from the list, with others
possible? Maintenance issues here are actually sometimes contentious
even if the core kernel is fairly small.

 - security stuff

   Luto, Kees?

 - particular pain points. Any not mentioned?

 - other?

I'd like the maintainership summit list to be fairly small. Not even
50 people. Maybe 30. A group that can actually sit in a room for half
a day and talk to each other about the issues they have rather than
being talked to. And talk literally about *process* issues, not about
any particular technical issues within whatever subsystem. Bring up
peeves or wishes for actual process improvements?

Comments? People who should be involved? Or people who don't have any
particular issues and want to not be involved?

                   Linus

-----

 11118  David Miller
  6004  Greg KH
  5337  Dave Airlie
  5114  Ingo Molnar
  3918  Mauro Carvalho Chehab
  3381  Arnd Bergmann
  3096  Andrew Morton
  1803  Michael Ellerman
  1557  Takashi Iwai
  1414  Doug Ledford
  1341  Al Viro
  1304  Rafael Wysocki
  1233  Jens Axboe
  1221  Thomas Gleixner
  1045  Olof Johansson
   980  Linus Walleij
   924  James Bottomley
   792  Ralf Baechle
   788  Herbert Xu
   751  Stephen Boyd
   593  Martin Schwidefsky
   585  Jonathan Corbet
   529  Paolo Bonzini
   443  Ulf Hansson
   443  Bjorn Helgaas
   421  Chris Mason
   420  Mark Brown
   411  Dave Chinner
   410  James Morris
   399  Michal Marek
   383  Dmitry Torokhov
   361  Will Deacon
   353  Wolfram Sang
   320  Jiri Kosina
   310  Vineet Gupta
   299  Russell King
   298  Brian Norris
   285  Lee Jones
   280  Guenter Roeck
   279  Vinod Koul
   275  Rob Herring
   271  Radim Krčmář
   266  James Hogan
   251  Alexandre Belloni
   239  Sebastian Reichel
   221  Ted Ts'o
   220  Tejun Heo
   215  Dan Williams
   210  Shuah Khan
   208  Catalin Marinas

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Takashi Iwai]

On Tue, 18 Apr 2017 20:59:37 +0200,
Linus Torvalds wrote:
> 
>  - drivers
> 
>    Obviously we have Greg overall, with drm and rdma because of issues.
> 
>    An example here is that Christoph doesn't show up because I don't
> generally pull from him, but he's been all over and often crosses
> multiple driver subsystems, and has been involved in rdma too, so I'd
> add him just for that.
> 
>    Some driver subsystems may be huge (eg media and sound), but I
> don't know if they have issues. Mauro/Takashi?

In the sound area, majority of commits come from Mark Brown's ASoC
tree nowadays, and he should be included.  Mark is already in your
list, so we're covered pretty well by that.


Do you plan it to be attached with some major conference, or as a
stand-alone one?


thanks,

Takashi

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Dave Airlie]

>
>  11118  David Miller
>   6004  Greg KH
>   5337  Dave Airlie

I am not a number, I AM A FREE MAN.

>   5114  Ingo Molnar
>   3918  Mauro Carvalho Chehab
>   3381  Arnd Bergmann

Though it should probably be Arnd sending this considering he's number 6.

Sorry couldn't resist, on a more serious note, I'm unlikely to be
travelling much this year due to have a baby arriving hopefully in September.

I think for drm stuff Daniel Vetter is definitely the best person to have there,
if he can make it.

Dave.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Serge E. Hallyn]

Quoting Linus Torvalds (torvalds@linux-foundation.org):
>  - security stuff
>
>    Luto, Kees?

James Morris for the security tree?  Though it seems to run smoothly, so
probably no issues.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Greg Kroah-Hartman]

On Tue, Apr 18, 2017 at 11:59:37AM -0700, Linus Torvalds wrote:
>  - other?

I'd recommend Ben Hutchings for the help and work he does with stable
kernel releases as well.  Those numbers don't show up in your tree, but
in the stable releases, he is up there at with the amount of effort and
help he provides me, and the users of the trees he maintains (3.2 and
3.16 for Debian).  I figure the stable trees do tie into "process
improvements" for some discussions.

> I'd like the maintainership summit list to be fairly small. Not even
> 50 people. Maybe 30. A group that can actually sit in a room for half
> a day and talk to each other about the issues they have rather than
> being talked to. And talk literally about *process* issues, not about
> any particular technical issues within whatever subsystem. Bring up
> peeves or wishes for actual process improvements?

I'd like to see this happen as well, no technical issues can really be
discussed at the kernel summit anymore, we've gotten too big :(

thanks,

greg k-h

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Tue, 18 Apr 2017 20:59:37 +0200,
> Linus Torvalds wrote:
>>
>>    Some driver subsystems may be huge (eg media and sound), but I
>> don't know if they have issues. Mauro/Takashi?
>
> In the sound area, majority of commits come from Mark Brown's ASoC
> tree nowadays, and he should be included.  Mark is already in your
> list, so we're covered pretty well by that.

Ok. I don't know how many from that top-50 list we actually would be
able to have.

Not only do I think that we should try to limit it to maybe ~35 people
(random number taken out of thin air, but feels small enough that
people could basically just do it in a smaller room and keep things
personal), but the list is just the 50 kernel maintainer side.

And there's another important side to this if we can make it work: the
*users* of the kernel. Notably I'd really like to have kernel leads
from the main distros, ie Android, Fedora, Suse, Ubuntu.

I think that when we talk about process pain points, we definitely
need to have downstream involved. Greg is there with his stable
maintainer hat on too, but he's still "ours".

It would be really good to have whoever is in charge of the Android
kernel there (not manager, but tech lead), and not make it a blame
game, but really try to also talk about how we could perhaps bridge
that gap somehow.

I'm not sure who those people actually are, but I suspect this list
contains people who can point to each tech lead.. I think it's Laura
Abbott for Fedora, for example?

> Do you plan it to be attached with some major conference, or as a
> stand-alone one?

Oh, I was just assuming people were aware of the kernel summit <->
maintainer summit thing.

So this would be the maintainer side of the traditional kernel summit.

This year it would be October in Prague, co-located with the European
ELC / LinuxCon / OpenSourceSummit thing.

                  Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Tue, Apr 18, 2017 at 1:11 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> I'd recommend Ben Hutchings for the help and work he does with stable
> kernel releases as well.  Those numbers don't show up in your tree, but
> in the stable releases, he is up there at with the amount of effort and
> help he provides me, and the users of the trees he maintains (3.2 and
> 3.16 for Debian).  I figure the stable trees do tie into "process
> improvements" for some discussions.

Absolutely.  And as already mentioned, I'd like to extend it further
downstream and actually have distro people. Not tons, but to get the
discussion going about what works for them and in particular how (if?)
we could integrate those closer.

Android, of course, being the big elephant in the room. We're not
going to solve it, but at least have somebody there talking about
_their_ pain points.

                  Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jiri Kosina]

On Tue, 18 Apr 2017, Linus Torvalds wrote:

> I'm not sure who those people actually are, but I suspect this list
> contains people who can point to each tech lead.. I think it's Laura
> Abbott for Fedora, for example?

For SUSE, 3 out of 4 people who are actual internal branch maintainers 
(both enterprise and openSUSE products) are already included in your list, 
namely

	Takashi Iwai
	Michal Marek
	Jiri Kosina

On top of that, the fourth maintainer is

	Jeff Mahoney

We're maintaining quite a few codestreams in parallel (especially in the 
enterprise area), hence the split of responsibility.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Takashi Iwai]

On Tue, 18 Apr 2017 22:13:37 +0200,
Linus Torvalds wrote:
> 
> On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Tue, 18 Apr 2017 20:59:37 +0200,
> > Linus Torvalds wrote:
> >>
> >>    Some driver subsystems may be huge (eg media and sound), but I
> >> don't know if they have issues. Mauro/Takashi?
> >
> > In the sound area, majority of commits come from Mark Brown's ASoC
> > tree nowadays, and he should be included.  Mark is already in your
> > list, so we're covered pretty well by that.
> 
> Ok. I don't know how many from that top-50 list we actually would be
> able to have.
> 
> Not only do I think that we should try to limit it to maybe ~35 people
> (random number taken out of thin air, but feels small enough that
> people could basically just do it in a smaller room and keep things
> personal), but the list is just the 50 kernel maintainer side.
> 
> And there's another important side to this if we can make it work: the
> *users* of the kernel. Notably I'd really like to have kernel leads
> from the main distros, ie Android, Fedora, Suse, Ubuntu.
> 
> I think that when we talk about process pain points, we definitely
> need to have downstream involved. Greg is there with his stable
> maintainer hat on too, but he's still "ours".
> 
> It would be really good to have whoever is in charge of the Android
> kernel there (not manager, but tech lead), and not make it a blame
> game, but really try to also talk about how we could perhaps bridge
> that gap somehow.
> 
> I'm not sure who those people actually are, but I suspect this list
> contains people who can point to each tech lead.. I think it's Laura
> Abbott for Fedora, for example?

Well, if we think of the downstream, stable kernel maintainers play a
big role.  There is not only Greg, but there are a few others.
For example, in the case of SUSE, the branch maintainers (Jiri Kosina,
Michal Marek and me) are in your list, so it's good.  But, we take
fairly a big amount of changes through Jiri Slaby's 3.12.x stable tree
for SLE12 (up to SP1).  I guess other distros have such an aspect
depending on the kernel versions they base on.


> > Do you plan it to be attached with some major conference, or as a
> > stand-alone one?
> 
> Oh, I was just assuming people were aware of the kernel summit <->
> maintainer summit thing.

Yeah, sorry, I noticed that later after my reply.  A typical knee-jerk
post.

> So this would be the maintainer side of the traditional kernel summit.
> 
> This year it would be October in Prague, co-located with the European
> ELC / LinuxCon / OpenSourceSummit thing.

Alright, thanks.


Takashi

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Laurent Pinchart]

Hi Dave,

On Wednesday 19 Apr 2017 06:00:27 Dave Airlie wrote:
> >  11118  David Miller
> >  
> >   6004  Greg KH
> >   5337  Dave Airlie
> 
> I am not a number, I AM A FREE MAN.
> 
> >   5114  Ingo Molnar
> >   3918  Mauro Carvalho Chehab
> >   3381  Arnd Bergmann
> 
> Though it should probably be Arnd sending this considering he's number 6.
> 
> Sorry couldn't resist, on a more serious note, I'm unlikely to be
> travelling much this year due to have a baby arriving hopefully in
> September.
> 
> I think for drm stuff Daniel Vetter is definitely the best person to have
> there, if he can make it.

I was going to propose that, so I can only second your proposal.

Additionally, Daniel has invested lots of time and effort in the actual 
maintenance process of the DRM subsystem, experimenting with a scheme that is 
quite unique in the kernel as far as I can tell. For that reason I believe he 
would be a very good candidate for a maintainer summit.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Laura Abbott]

On 04/18/2017 01:13 PM, Linus Torvalds wrote:
> On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> On Tue, 18 Apr 2017 20:59:37 +0200,
>> Linus Torvalds wrote:
>>>
>>>    Some driver subsystems may be huge (eg media and sound), but I
>>> don't know if they have issues. Mauro/Takashi?
>>
>> In the sound area, majority of commits come from Mark Brown's ASoC
>> tree nowadays, and he should be included.  Mark is already in your
>> list, so we're covered pretty well by that.
> 
> Ok. I don't know how many from that top-50 list we actually would be
> able to have.
> 
> Not only do I think that we should try to limit it to maybe ~35 people
> (random number taken out of thin air, but feels small enough that
> people could basically just do it in a smaller room and keep things
> personal), but the list is just the 50 kernel maintainer side.
> 
> And there's another important side to this if we can make it work: the
> *users* of the kernel. Notably I'd really like to have kernel leads
> from the main distros, ie Android, Fedora, Suse, Ubuntu.
> 
> I think that when we talk about process pain points, we definitely
> need to have downstream involved. Greg is there with his stable
> maintainer hat on too, but he's still "ours".
> 
> It would be really good to have whoever is in charge of the Android
> kernel there (not manager, but tech lead), and not make it a blame
> game, but really try to also talk about how we could perhaps bridge
> that gap somehow.

I think the Android lead is Rom Lemarchand, or he would know the
best representative.

> 
> I'm not sure who those people actually are, but I suspect this list
> contains people who can point to each tech lead.. I think it's Laura
> Abbott for Fedora, for example?
> 

We're a team of two so there isn't really a tech lead per se. Justin
Forbes is the other full time Fedora kernel maintainer.

Laura

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Takashi Iwai]

On Tue, 18 Apr 2017 22:21:31 +0200,
Jiri Kosina wrote:
> 
> On Tue, 18 Apr 2017, Linus Torvalds wrote:
> 
> > I'm not sure who those people actually are, but I suspect this list
> > contains people who can point to each tech lead.. I think it's Laura
> > Abbott for Fedora, for example?
> 
> For SUSE, 3 out of 4 people who are actual internal branch maintainers 
> (both enterprise and openSUSE products) are already included in your list, 
> namely
> 
> 	Takashi Iwai
> 	Michal Marek
> 	Jiri Kosina
> 
> On top of that, the fourth maintainer is
> 
> 	Jeff Mahoney
> 
> We're maintaining quite a few codestreams in parallel (especially in the 
> enterprise area), hence the split of responsibility.

Yep, also we have the fifth maintainer, Jiri Slaby, for openSUSE
Tumbleweed stable kernel branch.  I forgot to mention, too.


Takashi

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Daniel Vetter]

On Tue, Apr 18, 2017 at 10:00 PM, Dave Airlie <airlied@gmail.com> wrote:
>>  11118  David Miller
>>   6004  Greg KH
>>   5337  Dave Airlie
>
> I am not a number, I AM A FREE MAN.
>
>>   5114  Ingo Molnar
>>   3918  Mauro Carvalho Chehab
>>   3381  Arnd Bergmann
>
> Though it should probably be Arnd sending this considering he's number 6.
>
> Sorry couldn't resist, on a more serious note, I'm unlikely to be
> travelling much this year due to have a baby arriving hopefully in September.
>
> I think for drm stuff Daniel Vetter is definitely the best person to have there,
> if he can make it.

It's on the same continent, I'm low on real excuses :-)

Depending what we talk about it might be useful to invite Sean Paul
and/or Jani Nikula as drm-misc co-maintainers (which really is the drm
core + subsystem wide refactorings + misc small drivers in one team
nowadays). Sean Paul is also doing ChromeOS from Google's pov, so
could bring that perspective.

For Android I think it'd be great to have Rom Lemarchand invited (he's
google's overall android kernel engineer). Especially on the drm side
we've made some great improvements with getting Android stuff running
on pure upstream over the last year (and not just as a pile of hacks
and shortcuts, but with all the features Android wants). From the
infrastructure pov it's essentially mission accomplished afaiui, and
the gaps are "just" with some of the drivers (but that's nothing new,
upstream open source gfx is still not supported by many vendors
unfortunately).

Sean, Jani&Rom on cc in case you need their mail address.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Tue, Apr 18, 2017 at 1:38 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Depending what we talk about it might be useful to invite Sean Paul
> and/or Jani Nikula as drm-misc co-maintainers (which really is the drm
> core + subsystem wide refactorings + misc small drivers in one team
> nowadays). Sean Paul is also doing ChromeOS from Google's pov, so
> could bring that perspective.

So I'm seeing problems keeping it to a small number. We *will* have to cut.

One thing to do is to perhaps require that everybody can talk about at
least one particular process pain-point with a suggested improvement.
Anybody who doesn't have a painpoint (or whose painpoint is something
they don't think can be fixed) could recuse themselves as being
"happy".

Of course, that's not likely to cut down on numbers _that_ much, so
we'll just have to be picky ;)

> For Android I think it'd be great to have Rom Lemarchand invited (he's
> google's overall android kernel engineer).

Good.

Side note: people should think about various infrastructure/testing
people too  So kernel.org, but also things like zero-day etc test
labs.

I do *not* think we needs tons and tons of developers - unless they
have particular maintenance issues.

Particular subsystems should aim to have one person per subsystem that
can speak for that subsystem, I think, unless there are big reasons
why we'd want more and it's particularly contentious.

If we end up with 20 developers / maintainers and 10 people who are
downstream / stable / infrastructure, I think we'd likely have a
reasonable mix.

I think that the top-ten list (that was originally cc'd) was
reasonably obvious, but it was literallty just a "first round".

And it's good to have numbers to show "these are clearly major
top-level maintainers", and people on that short-list should at least
point to an alternate like DaveA already did.

The longer list of 50 was more of a "and here's more people that show
up high in git that should then have other reasons to be there".

                 Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mauro Carvalho Chehab]

Em Tue, 18 Apr 2017 13:13:37 -0700
Linus Torvalds <torvalds@linux-foundation.org> escreveu:

> On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Tue, 18 Apr 2017 20:59:37 +0200,
> > Linus Torvalds wrote:  
> >>
> >>    Some driver subsystems may be huge (eg media and sound), but I
> >> don't know if they have issues. Mauro/Takashi?  

On media side, I convert all pull requests I receive in a quilt tree,
reviewing patch per patch. So, you won't see media sub-maintainers
on a top-50 list based on comitters. Among sub-maintainers, Hans Verkuil 
is doing a great job sub-maintaining V4L2 drivers, with is a significant
amount patches that come via my tree.

With regards to issues, I'd say that everything that touches the
process is relavant to media. Due to its nature, media devices are
very complex, and interact with a lot of subsystems, like DT, arch,
drm, input, network, i2c, staging, docs. So, I'm very interested on
all discussions related to process.

There is one particular issue that occurs to me, although I'm not sure
if it would fit on the new "maintainer summit" format: it is related
to how to group documentation. Also, this is actually Jon's call, but
I suspect that he may want to hear comments from the others.

Right now, all media documents are in a single book.

There is an alternate model of splitting documentation on multiple
documents, like, for example, grouping everything that is driver's API
on a single document that covers multiple subsystems.

While we could try to discuss this sort of thing via ML, I suspect
that this is the sort of thing that would be better to discuss it on
a forum with multiple maintainers, in order to see what would work best
for the main subsystems.

> > In the sound area, majority of commits come from Mark Brown's ASoC
> > tree nowadays, and he should be included.  Mark is already in your
> > list, so we're covered pretty well by that.  
> 
> Ok. I don't know how many from that top-50 list we actually would be
> able to have.
> 
> Not only do I think that we should try to limit it to maybe ~35 people
> (random number taken out of thin air, but feels small enough that
> people could basically just do it in a smaller room and keep things
> personal), but the list is just the 50 kernel maintainer side.
> 
> And there's another important side to this if we can make it work: the
> *users* of the kernel. Notably I'd really like to have kernel leads
> from the main distros, ie Android, Fedora, Suse, Ubuntu.
> 
> I think that when we talk about process pain points, we definitely
> need to have downstream involved. Greg is there with his stable
> maintainer hat on too, but he's still "ours".

Yeah, having a few downstream maintainers there could be interesting,
as we can get feedback about what should be improved in the process.

Thanks,
Mauro

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Daniel Vetter]

On Tue, Apr 18, 2017 at 10:56 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Apr 18, 2017 at 1:38 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>
>> Depending what we talk about it might be useful to invite Sean Paul
>> and/or Jani Nikula as drm-misc co-maintainers (which really is the drm
>> core + subsystem wide refactorings + misc small drivers in one team
>> nowadays). Sean Paul is also doing ChromeOS from Google's pov, so
>> could bring that perspective.
>
> So I'm seeing problems keeping it to a small number. We *will* have to cut.
>
> One thing to do is to perhaps require that everybody can talk about at
> least one particular process pain-point with a suggested improvement.
> Anybody who doesn't have a painpoint (or whose painpoint is something
> they don't think can be fixed) could recuse themselves as being
> "happy".
>
> Of course, that's not likely to cut down on numbers _that_ much, so
> we'll just have to be picky ;)

Yeah, Sean/Jani probably only make sense if we bikeshed group
maintainer models the entire day.

>> For Android I think it'd be great to have Rom Lemarchand invited (he's
>> google's overall android kernel engineer).
>
> Good.
>
> Side note: people should think about various infrastructure/testing
> people too  So kernel.org, but also things like zero-day etc test
> labs.

Hm, we're trying to build up a much more ambitious CI here for drm and
intel specifically, but nothing all that interesting yet relevant
beyond drm. What could be interesting (but not for the discussion
session, more for the general track) is getting our userspace CI team
to explain what they do. Except that it runs in userspace the gl
drivers are as much low-level driver nonsense as anything else as far
as drivers go, and the stuff they're pulling off is seriously
impressive. Millions of test runs each day (including pre-merge to
stop any regressions before they even get close to the tree),
contributor numbers and code size on par with a major Linux subsystem,
100+ different machines and all the fun of testing hw ("yep, that
killed all the machines, oops").

A hw testing bof thing for different (driver) subsystems to compare
notes might be good, but I'm not sure that'd be useful for the group
discussions really. Probably more talking to the audience than what
you're aiming for.

> I do *not* think we needs tons and tons of developers - unless they
> have particular maintenance issues.

I do think we overall have some big issues with all the folks who
decide not to contribute to upstream but still ship Linux. Android is
a big one, but socs in general suffer from this. Like you said in
another mail, pointing fingers is no use, least because if we put all
the blame on hw vendors there's nothing we can do on our side to
improve things :-)

Since they don't even show it's hard to find out who'd be a good rep,
so probably not much use getting them in as developers (or I have no
idea how at least). But I do think we have a big gap here (and e.g.
drm for a long time entirely lacked the android perspective in
upstream work, until upstream folks + google worked to fix that).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Stephen Rothwell]

Hi Linus,

On Tue, 18 Apr 2017 11:59:37 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> People who should be involved?

I guess I should put my hand up.  I suppose I can come up with some
process peeves :-)

-- 
Cheers,
Stephen Rothwell

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Shuah Khan]

On Tue, Apr 18, 2017 at 6:22 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Linus,
>
> On Tue, 18 Apr 2017 11:59:37 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> People who should be involved?
>
> I guess I should put my hand up.  I suppose I can come up with some
> process peeves :-)

Hi Linus and Stephen,

I have been seeing more instances of conflicts between kselftest tree
and mm, net, and x86. Not surprising. mm, net, amd x86 are the most
active areas for selftests and when new tests get added, they usually
depend on some feature. As as result, the test has to go through the
core tree. It has been resulting in conflicts with the regular
activity in kselftest tree.

Stephen has been seeing the conflicts when the trees get into
linux-next. Maybe something that could be addressed as a general topic
or if this is somewhat unique situation (it might be), I can work out
a plan offline with the maintainers involved. I don't think this topic
would require my presence at the summit. It could be easily discussed
on the mailing list.

thanks,
-- Shuah

>
> --
> Cheers,
> Stephen Rothwell
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 3101 bytes --]

On 4/18/2017 4:13 PM, Linus Torvalds wrote:
> On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> On Tue, 18 Apr 2017 20:59:37 +0200,
>> Linus Torvalds wrote:
>>>
>>>    Some driver subsystems may be huge (eg media and sound), but I
>>> don't know if they have issues. Mauro/Takashi?
>>
>> In the sound area, majority of commits come from Mark Brown's ASoC
>> tree nowadays, and he should be included.  Mark is already in your
>> list, so we're covered pretty well by that.
> 
> Ok. I don't know how many from that top-50 list we actually would be
> able to have.
> 
> Not only do I think that we should try to limit it to maybe ~35 people
> (random number taken out of thin air, but feels small enough that
> people could basically just do it in a smaller room and keep things
> personal), but the list is just the 50 kernel maintainer side.
> 
> And there's another important side to this if we can make it work: the
> *users* of the kernel. Notably I'd really like to have kernel leads
> from the main distros, ie Android, Fedora, Suse, Ubuntu.
> 
> I think that when we talk about process pain points, we definitely
> need to have downstream involved. Greg is there with his stable
> maintainer hat on too, but he's still "ours".
> 
> It would be really good to have whoever is in charge of the Android
> kernel there (not manager, but tech lead), and not make it a blame
> game, but really try to also talk about how we could perhaps bridge
> that gap somehow.
> 
> I'm not sure who those people actually are, but I suspect this list
> contains people who can point to each tech lead.. I think it's Laura
> Abbott for Fedora, for example?

There really is no pain point for Fedora.  They take a very simple
approach: in rawhide, they pull latest git once you hit the -rc cycles
and build it, otherwise it's the latest released kernel; in actual
releases, they pull stable tree point releases as they are released (not
long term stable, they upgrade to a new stable tree fairly regularly).
They really don't do much in the way of having to integrate changes into
their kernel (intentionally), it's just a constant rolling update game
using newer and newer tarballs.  So, the pain is not in Fedora, it's in
RHEL.  What we do there is so totally different from Fedora and hurts so
bad as a developer...but I don't know if you really care to even talk
about that at the summit since, to be fair, it's largely a consequence
of our business model.

>> Do you plan it to be attached with some major conference, or as a
>> stand-alone one?
> 
> Oh, I was just assuming people were aware of the kernel summit <->
> maintainer summit thing.
> 
> So this would be the maintainer side of the traditional kernel summit.
> 
> This year it would be October in Prague, co-located with the European
> ELC / LinuxCon / OpenSourceSummit thing.
> 
>                   Linus
> 


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote:
> On 4/18/2017 4:13 PM, Linus Torvalds wrote:
>>
>> I'm not sure who those people actually are, but I suspect this list
>> contains people who can point to each tech lead.. I think it's Laura
>> Abbott for Fedora, for example?
>
> There really is no pain point for Fedora.  They take a very simple
> approach: in rawhide, they pull latest git once you hit the -rc cycles
> and build it, otherwise it's the latest released kernel; in actual
> releases, they pull stable tree point releases as they are released (not
> long term stable, they upgrade to a new stable tree fairly regularly).
> They really don't do much in the way of having to integrate changes into
> their kernel (intentionally), it's just a constant rolling update game
> using newer and newer tarballs.  So, the pain is not in Fedora, it's in
> RHEL.  What we do there is so totally different from Fedora and hurts so
> bad as a developer...but I don't know if you really care to even talk
> about that at the summit since, to be fair, it's largely a consequence
> of our business model.

Yeah, I don't think we can do much about distros that intentionally
want to stay behind and backport. Admittedly Android seems to be very
much in that camp too, but I'd at least want to talk to them more.
RHEL I feel knows what it's doing and isn't causing the kinds of
issues Android is anyway.

That said, even with Fedora I think Laura was at the KS last year, and
did talk about what she sees as the stable kernel process. So Fedora
may not be a "painpoint", but may well be relevant for the "meet with
people and talk about process issues once a year".

Of course, if it really is a question of "we have no problems and no
reason to even be there" for Fedora, then that's one (or two) less
people to worry about ;)

                Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2284 bytes --]

On 4/19/2017 12:18 PM, Linus Torvalds wrote:
> On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote:
>> On 4/18/2017 4:13 PM, Linus Torvalds wrote:
>>>
>>> I'm not sure who those people actually are, but I suspect this list
>>> contains people who can point to each tech lead.. I think it's Laura
>>> Abbott for Fedora, for example?
>>
>> There really is no pain point for Fedora.  They take a very simple
>> approach: in rawhide, they pull latest git once you hit the -rc cycles
>> and build it, otherwise it's the latest released kernel; in actual
>> releases, they pull stable tree point releases as they are released (not
>> long term stable, they upgrade to a new stable tree fairly regularly).
>> They really don't do much in the way of having to integrate changes into
>> their kernel (intentionally), it's just a constant rolling update game
>> using newer and newer tarballs.  So, the pain is not in Fedora, it's in
>> RHEL.  What we do there is so totally different from Fedora and hurts so
>> bad as a developer...but I don't know if you really care to even talk
>> about that at the summit since, to be fair, it's largely a consequence
>> of our business model.
> 
> Yeah, I don't think we can do much about distros that intentionally
> want to stay behind and backport. Admittedly Android seems to be very
> much in that camp too, but I'd at least want to talk to them more.
> RHEL I feel knows what it's doing and isn't causing the kinds of
> issues Android is anyway.
> 
> That said, even with Fedora I think Laura was at the KS last year, and
> did talk about what she sees as the stable kernel process. So Fedora
> may not be a "painpoint", but may well be relevant for the "meet with
> people and talk about process issues once a year".

Entirely true.  And I probably shouldn't have said there is no pain
point for Fedora, because I shouldn't have put words in her mouth
anyway.  I would *expect* there is no pain point given their model (and
I've not seen the internal email discussions we see around our RHEL
kernels), but I can't speak beyond that.


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Justin Forbes]

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

On Wed, Apr 19, 2017 at 11:18 AM, Linus Torvalds <
torvalds@linux-foundation.org> wrote:

> On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote:
> > On 4/18/2017 4:13 PM, Linus Torvalds wrote:
> >>
> >> I'm not sure who those people actually are, but I suspect this list
> >> contains people who can point to each tech lead.. I think it's Laura
> >> Abbott for Fedora, for example?
> >
> > There really is no pain point for Fedora.  They take a very simple
> > approach: in rawhide, they pull latest git once you hit the -rc cycles
> > and build it, otherwise it's the latest released kernel; in actual
> > releases, they pull stable tree point releases as they are released (not
> > long term stable, they upgrade to a new stable tree fairly regularly).
> > They really don't do much in the way of having to integrate changes into
> > their kernel (intentionally), it's just a constant rolling update game
> > using newer and newer tarballs.  So, the pain is not in Fedora, it's in
> > RHEL.  What we do there is so totally different from Fedora and hurts so
> > bad as a developer...but I don't know if you really care to even talk
> > about that at the summit since, to be fair, it's largely a consequence
> > of our business model.
>
>
There are certainly pain points in Fedora, very much related to this
model.  The approach is simple, the implementation could be better.  Our
pain points are just very different from the RHEL pain points.
For instance, while stable has been a great success over the years, the
policy is no fixes in stable until they are in head.  Unfortunately a lot
of simple fixes end up in queued in maintainer trees for -next and never
end up in head until the next merge window.   I don't know what the answer
here is, changing the stable policy in this regard doesn't seem like the
best solution.


> Yeah, I don't think we can do much about distros that intentionally
> want to stay behind and backport. Admittedly Android seems to be very
> much in that camp too, but I'd at least want to talk to them more.
> RHEL I feel knows what it's doing and isn't causing the kinds of
> issues Android is anyway.
>
> That said, even with Fedora I think Laura was at the KS last year, and
> did talk about what she sees as the stable kernel process. So Fedora
> may not be a "painpoint", but may well be relevant for the "meet with
> people and talk about process issues once a year".
>
> Of course, if it really is a question of "we have no problems and no
> reason to even be there" for Fedora, then that's one (or two) less
> people to worry about ;)


Laura is a good candidate to discuss the Fedora pain points.

Justin

[-- Attachment #2: Type: text/html, Size: 3504 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Laura Abbott]

On 04/19/2017 09:18 AM, Linus Torvalds wrote:
> On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote:
>> On 4/18/2017 4:13 PM, Linus Torvalds wrote:
>>>
>>> I'm not sure who those people actually are, but I suspect this list
>>> contains people who can point to each tech lead.. I think it's Laura
>>> Abbott for Fedora, for example?
>>
>> There really is no pain point for Fedora.  They take a very simple
>> approach: in rawhide, they pull latest git once you hit the -rc cycles
>> and build it, otherwise it's the latest released kernel; in actual
>> releases, they pull stable tree point releases as they are released (not
>> long term stable, they upgrade to a new stable tree fairly regularly).
>> They really don't do much in the way of having to integrate changes into
>> their kernel (intentionally), it's just a constant rolling update game
>> using newer and newer tarballs.  So, the pain is not in Fedora, it's in
>> RHEL.  What we do there is so totally different from Fedora and hurts so
>> bad as a developer...but I don't know if you really care to even talk
>> about that at the summit since, to be fair, it's largely a consequence
>> of our business model.
> 
> Yeah, I don't think we can do much about distros that intentionally
> want to stay behind and backport. Admittedly Android seems to be very
> much in that camp too, but I'd at least want to talk to them more.
> RHEL I feel knows what it's doing and isn't causing the kinds of
> issues Android is anyway.
> 
> That said, even with Fedora I think Laura was at the KS last year, and
> did talk about what she sees as the stable kernel process. So Fedora
> may not be a "painpoint", but may well be relevant for the "meet with
> people and talk about process issues once a year".
> 
> Of course, if it really is a question of "we have no problems and no
> reason to even be there" for Fedora, then that's one (or two) less
> people to worry about ;)
> 
>                  Linus

I wouldn't say we have no problems or pain points. It's a different
kind of paint point than what RHEL deals with. The building and
integration is simpler but the frequent updates can be difficult
for end users who are not experienced kernel developers. I brought
up bug reporting last year and I still consider that to be an
issue this year. A good example is 
https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really 
make progress until
I sent out a separate e-mail thread summarizing the bisections
people did. There are only 2 of us on Fedora so having to
guide users along on every bug doesn't scale well.

The irregular timing of stable updates also makes it difficult
to give an answer to users who want to know "when will this
be fixed".

Thanks,
Laura

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Laurent Pinchart]

Hi Linus,

On Tuesday 18 Apr 2017 13:13:37 Linus Torvalds wrote:
> On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Tue, 18 Apr 2017 20:59:37 +0200, Linus Torvalds wrote:
> >> Some driver subsystems may be huge (eg media and sound), but I
> >> don't know if they have issues. Mauro/Takashi?
> > 
> > In the sound area, majority of commits come from Mark Brown's ASoC
> > tree nowadays, and he should be included.  Mark is already in your
> > list, so we're covered pretty well by that.
> 
> Ok. I don't know how many from that top-50 list we actually would be
> able to have.
> 
> Not only do I think that we should try to limit it to maybe ~35 people
> (random number taken out of thin air, but feels small enough that
> people could basically just do it in a smaller room and keep things
> personal), but the list is just the 50 kernel maintainer side.
> 
> And there's another important side to this if we can make it work: the
> *users* of the kernel. Notably I'd really like to have kernel leads
> from the main distros, ie Android, Fedora, Suse, Ubuntu.

Agreed, for a maintainer summit to be useful, we need to have multiple sides 
present. Gathering core maintainers with key representatives of the downstream 
communities around the table is great, but I think we would be missing one 
category whose opinion is equally important: kernel developers.

When everything goes well developers can be represented by their maintainers. 
That's the case where the process flows smoothly, so there isn't likely to be 
much to discuss. However, problems occurring in the maintenance process are 
likely to result in, if not conflicts, at least different views between 
maintainers and developers, in which case developers won't be represented at 
the summit.

I'm not sure how to handle that. I certainly don't want to increase the number 
of attendees to include key representatives of developers (and while I'd be 
very curious to see how they would be selected, I doubt it would work in 
practice), but I also believe we need to address this class of maintainership 
issues.

> I think that when we talk about process pain points, we definitely
> need to have downstream involved. Greg is there with his stable
> maintainer hat on too, but he's still "ours".
> 
> It would be really good to have whoever is in charge of the Android
> kernel there (not manager, but tech lead), and not make it a blame
> game, but really try to also talk about how we could perhaps bridge
> that gap somehow.
> 
> I'm not sure who those people actually are, but I suspect this list
> contains people who can point to each tech lead.. I think it's Laura
> Abbott for Fedora, for example?
> 
> > Do you plan it to be attached with some major conference, or as a
> > stand-alone one?
> 
> Oh, I was just assuming people were aware of the kernel summit <->
> maintainer summit thing.
> 
> So this would be the maintainer side of the traditional kernel summit.
> 
> This year it would be October in Prague, co-located with the European
> ELC / LinuxCon / OpenSourceSummit thing.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Agreed, for a maintainer summit to be useful, we need to have multiple sides
> present. Gathering core maintainers with key representatives of the downstream
> communities around the table is great, but I think we would be missing one
> category whose opinion is equally important: kernel developers.
>
> When everything goes well developers can be represented by their maintainers.
> That's the case where the process flows smoothly, so there isn't likely to be
> much to discuss. However, problems occurring in the maintenance process are
> likely to result in, if not conflicts, at least different views between
> maintainers and developers, in which case developers won't be represented at
> the summit.
>
> I'm not sure how to handle that. I certainly don't want to increase the number
> of attendees to include key representatives of developers (and while I'd be
> very curious to see how they would be selected, I doubt it would work in
> practice), but I also believe we need to address this class of maintainership
> issues.

I do agree that it would be a great thing to have a "bitch at
maintainers" session where developers get to vent frustration at how
their patches are (or are _not_) accepted by maintainers.

I know we've had issues in the VFS layer, with Al sometimes
effectively dropping off the intenet for a time, for example.  And I'm
sure it happens elsewhere too, I'm just aware of the VFS side because
it's one of the areas where I end up personally being a secondary
maintainer.

But the problem with that "bitch at maintainers" thing is that I can't
for the life of me come up with a sane small set of people to do that.
So I don't see it happening ;(

Anyway, I have tried to gather "other groups" that aren't in that
top-10 maintainers list, but are examples of people "around" the
maintenance issues:

 - stable and linux-next:

   Ben Hutchings (stable)
   Stephen Rothwell (linux-next)

 - Infrastructure:

   Konstantin Ryabitsev (k.org)
   Fengguang Wu (kernel test robot)
   Steven Rostedt (ktest)
   Shuah Khan (tools/testing)
   Thorsten Leemhuis (regression tracking)
   Jonathan Corbet (documentation)

 - Security:

   Andy Lutomirski (security and core)
   Kees Cook (security)
   James Morris (security subsystem)

 - distro people:

   Laura Abbott (Fedora)
   Jiri Kosina (MM? JM?) (Suse)
   Rom Lemarchand (Android)

 - Hw vendor people?
 - Sponsor people?

but I can't come up with a sane set of "leaf developers" or anything
like that. We've just got too many. That's obviously a good problem to
have, but it doesn't fit with the maintainer summit, because unless
somebody can come up with some kind of prototypical spokesperson for
that group (and to me, that doesn't seem likely), I don't see how to
do it.

(And I still suspect that we do want coverage of some remaining
maintainership areas, ie filesystem and block layer, because the
"top-10 maintainers" don't cover that at all. And I haven't heard
suggestions for the networking side either, still assuming that Daem
isn't interested since he never has been before..)

                     Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jens Axboe]

On 04/19/2017 01:40 PM, Linus Torvalds wrote:
> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>>
>> Agreed, for a maintainer summit to be useful, we need to have multiple sides
>> present. Gathering core maintainers with key representatives of the downstream
>> communities around the table is great, but I think we would be missing one
>> category whose opinion is equally important: kernel developers.
>>
>> When everything goes well developers can be represented by their maintainers.
>> That's the case where the process flows smoothly, so there isn't likely to be
>> much to discuss. However, problems occurring in the maintenance process are
>> likely to result in, if not conflicts, at least different views between
>> maintainers and developers, in which case developers won't be represented at
>> the summit.
>>
>> I'm not sure how to handle that. I certainly don't want to increase the number
>> of attendees to include key representatives of developers (and while I'd be
>> very curious to see how they would be selected, I doubt it would work in
>> practice), but I also believe we need to address this class of maintainership
>> issues.
> 
> I do agree that it would be a great thing to have a "bitch at
> maintainers" session where developers get to vent frustration at how
> their patches are (or are _not_) accepted by maintainers.
> 
> I know we've had issues in the VFS layer, with Al sometimes
> effectively dropping off the intenet for a time, for example.  And I'm
> sure it happens elsewhere too, I'm just aware of the VFS side because
> it's one of the areas where I end up personally being a secondary
> maintainer.
> 
> But the problem with that "bitch at maintainers" thing is that I can't
> for the life of me come up with a sane small set of people to do that.
> So I don't see it happening ;(
> 
> Anyway, I have tried to gather "other groups" that aren't in that
> top-10 maintainers list, but are examples of people "around" the
> maintenance issues:
> 
>  - stable and linux-next:
> 
>    Ben Hutchings (stable)
>    Stephen Rothwell (linux-next)
> 
>  - Infrastructure:
> 
>    Konstantin Ryabitsev (k.org)
>    Fengguang Wu (kernel test robot)
>    Steven Rostedt (ktest)
>    Shuah Khan (tools/testing)
>    Thorsten Leemhuis (regression tracking)
>    Jonathan Corbet (documentation)
> 
>  - Security:
> 
>    Andy Lutomirski (security and core)
>    Kees Cook (security)
>    James Morris (security subsystem)
> 
>  - distro people:
> 
>    Laura Abbott (Fedora)
>    Jiri Kosina (MM? JM?) (Suse)
>    Rom Lemarchand (Android)
> 
>  - Hw vendor people?
>  - Sponsor people?
> 
> but I can't come up with a sane set of "leaf developers" or anything
> like that. We've just got too many. That's obviously a good problem to
> have, but it doesn't fit with the maintainer summit, because unless
> somebody can come up with some kind of prototypical spokesperson for
> that group (and to me, that doesn't seem likely), I don't see how to
> do it.
> 
> (And I still suspect that we do want coverage of some remaining
> maintainership areas, ie filesystem and block layer, because the
> "top-10 maintainers" don't cover that at all. And I haven't heard
> suggestions for the networking side either, still assuming that Daem
> isn't interested since he never has been before..)

I haven't piped up yet, but the block layer was represented in your
initial top-20 (or something like that) list. I can attend if you want
representation on that side.

I'll also mention that upstream kernel users aren't "just" distros.
Facebook is a large consumer of upstream, and we feed everything we do
back as well. I suspect we have at least as many users (or more) than
some of the distros :-)

-- 
Jens Axboe

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Laurent Pinchart]

Hi Linus,

On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote:
> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote:
> > Agreed, for a maintainer summit to be useful, we need to have multiple
> > sides present. Gathering core maintainers with key representatives of the
> > downstream communities around the table is great, but I think we would be
> > missing one category whose opinion is equally important: kernel
> > developers.
> > 
> > When everything goes well developers can be represented by their
> > maintainers. That's the case where the process flows smoothly, so there
> > isn't likely to be much to discuss. However, problems occurring in the
> > maintenance process are likely to result in, if not conflicts, at least
> > different views between maintainers and developers, in which case
> > developers won't be represented at the summit.
> > 
> > I'm not sure how to handle that. I certainly don't want to increase the
> > number of attendees to include key representatives of developers (and
> > while I'd be very curious to see how they would be selected, I doubt it
> > would work in practice), but I also believe we need to address this class
> > of maintainership issues.
> 
> I do agree that it would be a great thing to have a "bitch at
> maintainers" session where developers get to vent frustration at how
> their patches are (or are _not_) accepted by maintainers.
> 
> I know we've had issues in the VFS layer, with Al sometimes
> effectively dropping off the intenet for a time, for example.  And I'm
> sure it happens elsewhere too, I'm just aware of the VFS side because
> it's one of the areas where I end up personally being a secondary
> maintainer.
> 
> But the problem with that "bitch at maintainers" thing is that I can't
> for the life of me come up with a sane small set of people to do that.
> So I don't see it happening ;(

I currently don't have any good idea to make that happen either, but I'll keep 
thinking about it :-) More than bitching at maintainers, I believe that lots 
of developers, especially "smaller" or infrequent kernel contributors, are 
frustrated by maintainership issues that the related maintainers might not 
even be aware of.

One idea I've been thinking of was to gather constructive feedback (or just 
feedback that would then be filtered out of pointless finger-pointing and 
bitching) about our maintainers, aggregate it periodically, and submit it to 
the maintainers, possibly in an anonymized form. A maintainer summit is 
certainly no place to gather that feedback, but could be an occasion to decide 
whether such a process would be deemed useful. I for one, while I only 
maintain drivers and not whole subsystems, would certainly welcome 
constructive criticism in that area.

> Anyway, I have tried to gather "other groups" that aren't in that
> top-10 maintainers list, but are examples of people "around" the
> maintenance issues:
> 
>  - stable and linux-next:
> 
>    Ben Hutchings (stable)
>    Stephen Rothwell (linux-next)
> 
>  - Infrastructure:
> 
>    Konstantin Ryabitsev (k.org)
>    Fengguang Wu (kernel test robot)
>    Steven Rostedt (ktest)
>    Shuah Khan (tools/testing)
>    Thorsten Leemhuis (regression tracking)
>    Jonathan Corbet (documentation)
> 
>  - Security:
> 
>    Andy Lutomirski (security and core)
>    Kees Cook (security)
>    James Morris (security subsystem)
> 
>  - distro people:
> 
>    Laura Abbott (Fedora)
>    Jiri Kosina (MM? JM?) (Suse)
>    Rom Lemarchand (Android)
> 
>  - Hw vendor people?
>  - Sponsor people?
> 
> but I can't come up with a sane set of "leaf developers" or anything
> like that. We've just got too many. That's obviously a good problem to
> have, but it doesn't fit with the maintainer summit, because unless
> somebody can come up with some kind of prototypical spokesperson for
> that group (and to me, that doesn't seem likely), I don't see how to
> do it.
> 
> (And I still suspect that we do want coverage of some remaining
> maintainership areas, ie filesystem and block layer, because the
> "top-10 maintainers" don't cover that at all. And I haven't heard
> suggestions for the networking side either, still assuming that Daem
> isn't interested since he never has been before..)

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Wed, 2017-04-19 at 22:50 +0300, Laurent Pinchart wrote:
> Hi Linus,
> 
> On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote:
> > On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote:
> > > Agreed, for a maintainer summit to be useful, we need to have 
> > > multiple sides present. Gathering core maintainers with key
> > > representatives of the downstream communities around the table is 
> > > great, but I think we would be missing one category whose opinion 
> > > is equally important: kernel developers.
> > > 
> > > When everything goes well developers can be represented by their
> > > maintainers. That's the case where the process flows smoothly, so 
> > > there isn't likely to be much to discuss. However, problems 
> > > occurring in the maintenance process are likely to result in, if 
> > > not conflicts, at least different views between maintainers and 
> > > developers, in which case developers won't be represented at the
> > > summit.
> > > 
> > > I'm not sure how to handle that. I certainly don't want to 
> > > increase the number of attendees to include key representatives 
> > > of developers (and while I'd be very curious to see how they 
> > > would be selected, I doubt it would work in practice), but I also 
> > > believe we need to address this class of maintainership issues.
> > 
> > I do agree that it would be a great thing to have a "bitch at
> > maintainers" session where developers get to vent frustration at 
> > how their patches are (or are _not_) accepted by maintainers.
> > 
> > I know we've had issues in the VFS layer, with Al sometimes
> > effectively dropping off the intenet for a time, for example.  And 
> > I'm sure it happens elsewhere too, I'm just aware of the VFS side
> > because it's one of the areas where I end up personally being a 
> > secondary maintainer.
> > 
> > But the problem with that "bitch at maintainers" thing is that I 
> > can't for the life of me come up with a sane small set of people to 
> > do that. So I don't see it happening ;(
> 
> I currently don't have any good idea to make that happen either, but 
> I'll keep thinking about it :-) More than bitching at maintainers, I 
> believe that lots of developers, especially "smaller" or infrequent 
> kernel contributors, are frustrated by maintainership issues that the 
> related maintainers might not even be aware of.

Isn't it easy?  The Maintainers summit is going to be part of a larger
kernel track within LinuxCon EU  (not that everyone plans on staying
on, of course, but several will be).  Just put the bitch at Maintainers
session in that as a round table, so any attendee of LinuxCon EU can
come and complain if they want to.

I think also it might be a good idea to separate internal process
issues, which would be done in the small group from external ones,
which should, perhaps, have the Kernel track at LinuxCon visibility.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Konstantin Ryabitsev]

On Wed, Apr 19, 2017 at 12:40:47PM -0700, Linus Torvalds wrote:
> - Infrastructure:
>
>   Konstantin Ryabitsev (k.org)

I'll be at the summit (following my usual "shows up to kernel summits 
even when not invited by privilege of being LF staff" routine).

-K

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Josh Triplett]

On Wed, Apr 19, 2017 at 10:50:15PM +0300, Laurent Pinchart wrote:
> Hi Linus,
> 
> On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote:
> > On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote:
> > > Agreed, for a maintainer summit to be useful, we need to have multiple
> > > sides present. Gathering core maintainers with key representatives of the
> > > downstream communities around the table is great, but I think we would be
> > > missing one category whose opinion is equally important: kernel
> > > developers.
> > > 
> > > When everything goes well developers can be represented by their
> > > maintainers. That's the case where the process flows smoothly, so there
> > > isn't likely to be much to discuss. However, problems occurring in the
> > > maintenance process are likely to result in, if not conflicts, at least
> > > different views between maintainers and developers, in which case
> > > developers won't be represented at the summit.
> > > 
> > > I'm not sure how to handle that. I certainly don't want to increase the
> > > number of attendees to include key representatives of developers (and
> > > while I'd be very curious to see how they would be selected, I doubt it
> > > would work in practice), but I also believe we need to address this class
> > > of maintainership issues.
> > 
> > I do agree that it would be a great thing to have a "bitch at
> > maintainers" session where developers get to vent frustration at how
> > their patches are (or are _not_) accepted by maintainers.
> > 
> > I know we've had issues in the VFS layer, with Al sometimes
> > effectively dropping off the intenet for a time, for example.  And I'm
> > sure it happens elsewhere too, I'm just aware of the VFS side because
> > it's one of the areas where I end up personally being a secondary
> > maintainer.
> > 
> > But the problem with that "bitch at maintainers" thing is that I can't
> > for the life of me come up with a sane small set of people to do that.
> > So I don't see it happening ;(
> 
> I currently don't have any good idea to make that happen either, but I'll keep 
> thinking about it :-) More than bitching at maintainers, I believe that lots 
> of developers, especially "smaller" or infrequent kernel contributors, are 
> frustrated by maintainership issues that the related maintainers might not 
> even be aware of.
> 
> One idea I've been thinking of was to gather constructive feedback (or just 
> feedback that would then be filtered out of pointless finger-pointing and 
> bitching) about our maintainers, aggregate it periodically, and submit it to 
> the maintainers, possibly in an anonymized form. A maintainer summit is 
> certainly no place to gather that feedback, but could be an occasion to decide 
> whether such a process would be deemed useful. I for one, while I only 
> maintain drivers and not whole subsystems, would certainly welcome 
> constructive criticism in that area.
> 
> > Anyway, I have tried to gather "other groups" that aren't in that
> > top-10 maintainers list, but are examples of people "around" the
> > maintenance issues:
> > 
> >  - stable and linux-next:
> > 
> >    Ben Hutchings (stable)
> >    Stephen Rothwell (linux-next)
> > 
> >  - Infrastructure:
> > 
> >    Konstantin Ryabitsev (k.org)
> >    Fengguang Wu (kernel test robot)
> >    Steven Rostedt (ktest)
> >    Shuah Khan (tools/testing)
> >    Thorsten Leemhuis (regression tracking)
> >    Jonathan Corbet (documentation)
> > 
> >  - Security:
> > 
> >    Andy Lutomirski (security and core)
> >    Kees Cook (security)
> >    James Morris (security subsystem)
> > 
> >  - distro people:
> > 
> >    Laura Abbott (Fedora)
> >    Jiri Kosina (MM? JM?) (Suse)
> >    Rom Lemarchand (Android)
> > 
> >  - Hw vendor people?
> >  - Sponsor people?
> > 
> > but I can't come up with a sane set of "leaf developers" or anything
> > like that. We've just got too many. That's obviously a good problem to
> > have, but it doesn't fit with the maintainer summit, because unless
> > somebody can come up with some kind of prototypical spokesperson for
> > that group (and to me, that doesn't seem likely), I don't see how to
> > do it.

I'd definitely like to see an "issues that affect casual/occasional
contributors" discussion; it wouldn't really fit the maintainer summit,
but I like James' suggestion of doing it as part of the attached
LinuxCon.

In terms of framing, though, I'd suggest keeping it focused on "what
issues have you personally encountered or directly observed", rather
than "what random process ideas do you have".  The latter would go
downhill very quickly; the former seems much more likely to produce
productive feedback on real problems.  (It's less important that they
come with potential solutions than that the relevant problems get
recorded for subsequent consideration.)

Will the maintainer summit occur *after* the overlapped conference, or
*before*?  If after, then it'd be plausible to have a "let's talk about
what we heard" session in the maintainer summit.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jiri Kosina]

On Wed, 19 Apr 2017, Linus Torvalds wrote:

>  - distro people:
> 
>    Laura Abbott (Fedora)
>    Jiri Kosina (MM? JM?) (Suse)
>    Rom Lemarchand (Android)

I think that having RHEL kernel maintainer(s) present would be beneficial 
as well (especially wrt. anything related to stable, as I believe they're 
as much influenced by it as we are with SLES). I have no idea who that 
person / those poeple are though.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote:
> I'd like the maintainership summit list to be fairly small. Not even
> 50 people. Maybe 30. A group that can actually sit in a room for half
> a day and talk to each other about the issues they have rather than
> being talked to. And talk literally about *process* issues, not about
> any particular technical issues within whatever subsystem. Bring up
> peeves or wishes for actual process improvements?
> 
> Comments? People who should be involved? Or people who don't have any
> particular issues and want to not be involved?

I'd like closure on one process issue, if we could achieve it:

Maintainer script automation: Quite a few of us have maintainer scripts
that send automated email notifications of the status of patches in the
tree (mostly to stop people flooding the lists with questions about
what happened to their patches).  We did a script show and tell at the
last kernel summit, but perhaps we could get closure on a couple of
issues:

   1. Since most people agree that these form of notifications are useful,
      should we have a standard email for it (or at least a list of things
      which should be in that email, like commit-id, tree, maintainer,
      mailing list and the version of the kernel it is expected to be
      pushed for).
   2. Given that we all run ad-hoc infrastructure to produce these emails,
      could we get a set of blessed scripts up on kernel.org for all
      comers so we can use the central infrastructure rather than rolling
      our own.

The other things I think it might do us all good is to have a frank
session on "tasteful rebasing".  We've come around (finally) to the
conclusion that rebasing isn't always bad.  My own opinion is that
rebasing to fix issues in patches (particularly those marked for
stable) so they can backport cleanly and atomically.  There's also less
of a consensus that rebasing to clean up history is a reasonably good
thing (provided it's not done just before requesting a pull).  However,
we have a divergence of opinions not just on whether we should rebase,
but what constitutes a tasteful rebase.  Just telling people,
particularly would be new maintainers, that it's a judgement call
always is unhelpful, we could do with putting together some more
detailed guidance (assuming we can agree on it).

Finally, since Daniel Vetter brought it up, having CI tests is seen as
a requirement for most git automation nowadays.  I tend to see 0day
plus my user base as the CI infrastructure but we should discuss
whether this is adequate.  I think 0day and linux-next pick up most
merge and generic test issues, and no-one has all the hardware to run a
true driver CI, so perhaps this is the best we can do, but we should at
least discuss whether we want to try to do better.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Arnd Bergmann]

On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> What I _would_ like to see is those top maintainers suggest
> "submaintainer" names. Particularly Davem, since he doesn't tend to
> want to come to the kernel summit, and being at the top of the list
> that's a kind of big gaping hole. I guess we haven't had all that many
> _problems_ within networking, but if we talk maintainership issues,
> it's certainly a bit odd if it's entirely lacking. We have both core
> networking and network drivers that both fall under "davem" as far as
> my pull statistics go.

For ARM, the work also tends to be fairly spread out across many
people, with few of us being overly important. [I think that while Olof and
I had similar shares of work in pulling in patches, I ended up in one of
the top spots because I happened to send more pull requests during
the last year, and I also did quite a bit of kernel stuff outside of
arch/arm.]

So while there is no need for having lots of ARM platform maintainers,
I would like to see some of the people that I interact with that also
work with a larger number of other maintainers:

- One of the device tree maintainers (Rob Herring, Frank Rowand,
  Mark Rutland), they inevitably deal with almost all device driver
  writers at some point

- One of the CLK subsystem maintainers (Michael Turquette,
  Stephen Boyd), they also interact with a large number of
  subsystem and platform maintainers, and we have had some
  disagreements particularly when dealing with three subsystems
  (clk, arm-soc and a device driver) in one patch series.

- One or two ARM platform maintainers, ideally one that also
  maintains another kernel subsystem. The platforms with  the most
  changes are usually sunxi (Maxime Ripard), OMAP (Tony
  Lindgren), Renesas (Simon Horman), Broadcom (Florian
  Fainelli), Qualcomm (Andy Gross) and Freescale (Shawn Guo).

- One or two of the ARM32/ARM64 architecture people: Russell
  King, Catalin Marinas, Will Deacon.

      Arnd

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jiri Kosina]

On Wed, 19 Apr 2017, James Bottomley wrote:

>    1. Since most people agree that these form of notifications are useful,
>       should we have a standard email for it (or at least a list of things
>       which should be in that email, like commit-id, tree, maintainer,
>       mailing list and the version of the kernel it is expected to be
>       pushed for).
>    2. Given that we all run ad-hoc infrastructure to produce these emails,
>       could we get a set of blessed scripts up on kernel.org for all
>       comers so we can use the central infrastructure rather than rolling
>       our own.

Just to make sure that we don't repeat a discussion that has already 
happened, see my proposal from 2015

	https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/001287.html

It didn't receive too much positive traction though.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Andy Lutomirski]

On Tue, Apr 18, 2017 at 11:59 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The kernel summit is apparently in October, and I promised last year
> to at least get the ball rolling with the people *I* would like to
> see.

What's the nominal subject matter?  I'd be happy to attend, but I only
sort-of maintain anything, so, to the extent it's focused on
maintenance, I can stay away (down the hallway?) for size reasons too.

>  - security stuff
>
>    Luto, Kees?

Hi!

>
>  - architectures
>
>    Pretty much covered by x86, arm, powerpc, and those architectures
> should talk about who within the group would attend.

Since I have a habit of stirring up arch stuff, I'd be happy to talk
about arch issues if they're relevant.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Laurent Pinchart]

Hi Josh,

On Wednesday 19 Apr 2017 13:14:29 Josh Triplett wrote:
> On Wed, Apr 19, 2017 at 10:50:15PM +0300, Laurent Pinchart wrote:
> > On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote:
> >> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote:
> >>> Agreed, for a maintainer summit to be useful, we need to have multiple
> >>> sides present. Gathering core maintainers with key representatives of
> >>> the downstream communities around the table is great, but I think we
> >>> would be missing one category whose opinion is equally important:
> >>> kernel developers.
> >>> 
> >>> When everything goes well developers can be represented by their
> >>> maintainers. That's the case where the process flows smoothly, so
> >>> there isn't likely to be much to discuss. However, problems occurring
> >>> in the maintenance process are likely to result in, if not conflicts,
> >>> at least different views between maintainers and developers, in which
> >>> case developers won't be represented at the summit.
> >>> 
> >>> I'm not sure how to handle that. I certainly don't want to increase
> >>> the number of attendees to include key representatives of developers
> >>> (and while I'd be very curious to see how they would be selected, I
> >>> doubt it would work in practice), but I also believe we need to
> >>> address this class of maintainership issues.
> >> 
> >> I do agree that it would be a great thing to have a "bitch at
> >> maintainers" session where developers get to vent frustration at how
> >> their patches are (or are _not_) accepted by maintainers.
> >> 
> >> I know we've had issues in the VFS layer, with Al sometimes
> >> effectively dropping off the intenet for a time, for example.  And I'm
> >> sure it happens elsewhere too, I'm just aware of the VFS side because
> >> it's one of the areas where I end up personally being a secondary
> >> maintainer.
> >> 
> >> But the problem with that "bitch at maintainers" thing is that I can't
> >> for the life of me come up with a sane small set of people to do that.
> >> So I don't see it happening ;(
> > 
> > I currently don't have any good idea to make that happen either, but I'll
> > keep thinking about it :-) More than bitching at maintainers, I believe
> > that lots of developers, especially "smaller" or infrequent kernel
> > contributors, are frustrated by maintainership issues that the related
> > maintainers might not even be aware of.
> > 
> > One idea I've been thinking of was to gather constructive feedback (or
> > just feedback that would then be filtered out of pointless finger-pointing
> > and bitching) about our maintainers, aggregate it periodically, and submit
> > it to the maintainers, possibly in an anonymized form. A maintainer summit
> > is certainly no place to gather that feedback, but could be an occasion
> > to decide whether such a process would be deemed useful. I for one, while
> > I only maintain drivers and not whole subsystems, would certainly welcome
> > constructive criticism in that area.
> > 
> >> Anyway, I have tried to gather "other groups" that aren't in that
> >> top-10 maintainers list, but are examples of people "around" the
> >> 
> >> maintenance issues:
> >>  - stable and linux-next:
> >>    Ben Hutchings (stable)
> >>    Stephen Rothwell (linux-next)
> >>  
> >>  - Infrastructure:
> >>    Konstantin Ryabitsev (k.org)
> >>    Fengguang Wu (kernel test robot)
> >>    Steven Rostedt (ktest)
> >>    Shuah Khan (tools/testing)
> >>    Thorsten Leemhuis (regression tracking)
> >>    Jonathan Corbet (documentation)
> >>  
> >>  - Security:
> >>    Andy Lutomirski (security and core)
> >>    Kees Cook (security)
> >>    James Morris (security subsystem)
> >>  
> >>  - distro people:
> >>    Laura Abbott (Fedora)
> >>    Jiri Kosina (MM? JM?) (Suse)
> >>    Rom Lemarchand (Android)
> >>  
> >>  - Hw vendor people?
> >>  - Sponsor people?
> >> 
> >> but I can't come up with a sane set of "leaf developers" or anything
> >> like that. We've just got too many. That's obviously a good problem to
> >> have, but it doesn't fit with the maintainer summit, because unless
> >> somebody can come up with some kind of prototypical spokesperson for
> >> that group (and to me, that doesn't seem likely), I don't see how to
> >> do it.
> 
> I'd definitely like to see an "issues that affect casual/occasional
> contributors" discussion; it wouldn't really fit the maintainer summit,
> but I like James' suggestion of doing it as part of the attached
> LinuxCon.

It's a good idea, I'd be happy to submit a proposal for such a session and 
lead it.

> In terms of framing, though, I'd suggest keeping it focused on "what
> issues have you personally encountered or directly observed", rather
> than "what random process ideas do you have".  The latter would go
> downhill very quickly; the former seems much more likely to produce
> productive feedback on real problems.  (It's less important that they
> come with potential solutions than that the relevant problems get
> recorded for subsequent consideration.)

I agree. I would extend it to "what issues have you or anyone your represent 
personally encountered", as I don't expect most of the casual/occasional 
contributors to attend the conference.

> Will the maintainer summit occur *after* the overlapped conference, or
> *before*?  If after, then it'd be plausible to have a "let's talk about
> what we heard" session in the maintainer summit.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Wed, Apr 19, 2017 at 2:05 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Apr 18, 2017 at 11:59 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> The kernel summit is apparently in October, and I promised last year
>> to at least get the ball rolling with the people *I* would like to
>> see.
>
> What's the nominal subject matter?  I'd be happy to attend, but I only
> sort-of maintain anything, so, to the extent it's focused on
> maintenance, I can stay away (down the hallway?) for size reasons too.

I think the nominal subject matter is "any process issue".

We used to have all these specific technical issues, and talk about
particular subsystems etc. That is *not* what this would be about, and
would be outside the scope of the maintainer thing.

People probably still want to have hallway discussions about things
like that, of course, and maybe the kernel summit ends up being a good
time to catch the right people, but it wouldn't be the maintainer
summit part.

But anything that has to not so much with any _particular_ part of the
kernel, and is rather about some process issue, would be up for grabs.

So questions would be around things like code organization changes or
anything that cuts across subsystems and might want some hook into the
process.

IOW, things like security disclosure rules, test coverage, random
infrastructure issues, pointing at portions of the kernel that have
spotty or no maintainership, things like that.

Is there something that could be automated better and we could ask the
infrastructure people (whether k.org or test robot or whatever) for?

Or going the other way, is there something the infrastructure people
would like us to do so that they'd be able to do more?

Or our interaction (or lack there-of) with the distro people?

So anything like that - but not subsystem specific discussion about
how to solve some problem (those would be better done at mini-summits
for that subsystem, which obviously might be co-located).

I *think* we agreed last year to try to limit things to just half a
day, and a small enough group that we won't be running out of oxygen
in the room.

I think that if we have 30 people and everybody has some particular
process gripe in mind that they think they could talk about for five
minutes, we'll easily be able to fill half a day.

The corollary to that is that if you don't have a process issue in
mind, and don't expect others to be griping about you, maybe you don't
want to be there.

                Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Geert Uytterhoeven]

Hi Justin,

On Wed, Apr 19, 2017 at 8:11 PM, Justin Forbes <jforbes@redhat.com> wrote:
> For instance, while stable has been a great success over the years, the
> policy is no fixes in stable until they are in head.  Unfortunately a lot of
> simple fixes end up in queued in maintainer trees for -next and never end up
> in head until the next merge window.   I don't know what the answer here is,
> changing the stable policy in this regard doesn't seem like the best
> solution.

I think this has been discussed before: it's about finding a good balance
between fixing bugs, and making sure the fixes don't cause regressions.

Even with the policy of no fixes in stable until they are in head, we sometimes
end up with fixes in stable that do introduce regressions.

I believe someone has statistics about that?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jonathan Corbet]

On Tue, 18 Apr 2017 18:15:06 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> wrote:

> There is one particular issue that occurs to me, although I'm not sure
> if it would fit on the new "maintainer summit" format: it is related
> to how to group documentation. Also, this is actually Jon's call, but
> I suspect that he may want to hear comments from the others.

I could imagine talking about a few documentation issues, including
interactions with the rest of the kernel.  Who has responsibility for
taking docs patches is often not clear, leading to multiple maintainers
picking them up or conflicts between trees.

We're also a ways into the Sphinx transition; I would be most curious to
hear how others think it is going and whether/how the process should
continue.

jon

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jiri Kosina]

On Wed, 19 Apr 2017, Jonathan Corbet wrote:

> We're also a ways into the Sphinx transition; I would be most curious to 
> hear how others think it is going and whether/how the process should 
> continue.

There is one piece of feedback I guess I can share right away on this -- 
I've heard so many complaints that Doc<tab>/kern<tab>-par<tab> completion 
stopped to yield Documentation/kernel-parameters.txt that it's not really 
funny any more :)

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Josh Triplett]

On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote:
> On Wed, 19 Apr 2017, Jonathan Corbet wrote:
> 
> > We're also a ways into the Sphinx transition; I would be most curious to 
> > hear how others think it is going and whether/how the process should 
> > continue.
> 
> There is one piece of feedback I guess I can share right away on this -- 
> I've heard so many complaints that Doc<tab>/kern<tab>-par<tab> completion 
> stopped to yield Documentation/kernel-parameters.txt that it's not really 
> funny any more :)

Is there any good reason we don't check in symlinks from the old
location to the new location, considering that the new version remains
readable in text form?

ln -sf Documentation/process/coding-style.rst Documentation/CodingStyle
ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt
...

Commit 852d21ae1fcdf0e4de6b5bfa730d29cb013c7ff3 already did this for one
such relocated file.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jiri Kosina]

On Wed, 19 Apr 2017, Josh Triplett wrote:

> ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt

I think you just sort of demonstrated my point -- you got confused by this 
transition as well.

Documentation/admin-guide/kernel-parameters.rst is rather useless.

Documentation/admin-guide/kernel-parameters.txt is likely what you're 
looking for.

This pattern can't be applied universally to other converted files though.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Josh Triplett]

On Thu, Apr 20, 2017 at 01:51:26AM +0200, Jiri Kosina wrote:
> On Wed, 19 Apr 2017, Josh Triplett wrote:
> > ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt
> 
> I think you just sort of demonstrated my point -- you got confused by this 
> transition as well.

I looked at commit 9d85025b0418163fae079c9ba8f8445212de8568, which
renamed Documentation/kernel-parameters.txt verbatim to
Documentation/admin-guide/kernel-parameters.rst , saw that the file
existed in the current kernel, and didn't look through the whole file to
see that it just contained an include.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Christoph Hellwig]

On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote:
> There is one piece of feedback I guess I can share right away on this -- 
> I've heard so many complaints that Doc<tab>/kern<tab>-par<tab> completion 
> stopped to yield Documentation/kernel-parameters.txt that it's not really 
> funny any more :)

Yeah.  All this moving files around really messed up my workflows.
Let's see if I'll be able to adjust eventually.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Julia Lawall]

> I'd definitely like to see an "issues that affect casual/occasional
> contributors" discussion; it wouldn't really fit the maintainer summit,
> but I like James' suggestion of doing it as part of the attached
> LinuxCon.

I would be happy to help with the organization of such a thing.

julia


> In terms of framing, though, I'd suggest keeping it focused on "what
> issues have you personally encountered or directly observed", rather
> than "what random process ideas do you have".  The latter would go
> downhill very quickly; the former seems much more likely to produce
> productive feedback on real problems.  (It's less important that they
> come with potential solutions than that the relevant problems get
> recorded for subsequent consideration.)
>
> Will the maintainer summit occur *after* the overlapped conference, or
> *before*?  If after, then it'd be plausible to have a "let's talk about
> what we heard" session in the maintainer summit.
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jani Nikula]

On Thu, 20 Apr 2017, Josh Triplett <josh@joshtriplett.org> wrote:
> On Thu, Apr 20, 2017 at 01:51:26AM +0200, Jiri Kosina wrote:
>> On Wed, 19 Apr 2017, Josh Triplett wrote:
>> > ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt
>> 
>> I think you just sort of demonstrated my point -- you got confused by this 
>> transition as well.
>
> I looked at commit 9d85025b0418163fae079c9ba8f8445212de8568, which
> renamed Documentation/kernel-parameters.txt verbatim to
> Documentation/admin-guide/kernel-parameters.rst , saw that the file
> existed in the current kernel, and didn't look through the whole file to
> see that it just contained an include.

Yes, unfortunately the 'make pdfdocs' build tripped over the long
preformatted text block, and e52347bd66f6 ("Documentation/admin-guide:
split the kernel parameter list to a separate file") was added as a
stopgap workaround. Alas, there's no proper fix yet. :(

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jani Nikula]

On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Yeah, I don't think we can do much about distros that intentionally
> want to stay behind and backport.

/me looks at https://www.kernel.org/

1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm
is based on a five years old release.

I just think the multitude of longterm kernels are sending a message
that it's perfectly fine to stay behind. Don't get me wrong, I know why
they are there, but I still think in the past the focus on encouraging
to always use the latest stable kernel was stronger.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Daniel Vetter]

On Wed, Apr 19, 2017 at 9:55 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> Isn't it easy?  The Maintainers summit is going to be part of a larger
> kernel track within LinuxCon EU  (not that everyone plans on staying
> on, of course, but several will be).  Just put the bitch at Maintainers
> session in that as a round table, so any attendee of LinuxCon EU can
> come and complain if they want to.

I don't think it's that easy. I guess due to the "interesting" stuff
we're doing in drm I get to hear some of the frustration stories from
leaf contributors. Picking a conference means you exclude folks who
won't go there (and Linux is so huge that there's simply no single
conference that would cover it all), but more important a common theme
I'm hearing is that frustrated folks don't want to speak up in public,
because if they piss of their maintainer, their problems just get
worse. On the other hand they lack the power and influence to fix
anything, so there's very little upside to speaking up about issues.
The usual solution seems to eventually just quietly abandon upstream,
or at least the particular subsystem.

The other thing is that because Linuxcon has such a wide audience you
might just get the peanut gallery kernel bashing from bystanders, not
feedback from actual (or at least potential) contributors.

Still worth trying I guess, but I wouldn't be surprised if there's not
much coming out of such a feedback session.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jani Nikula]

On Wed, 19 Apr 2017, Laura Abbott <labbott@redhat.com> wrote:
> I brought up bug reporting last year and I still consider that to be
> an issue this year. A good example is
> https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really
> make progress until I sent out a separate e-mail thread summarizing
> the bisections people did.

The service level at https://bugzilla.kernel.org heavily depends on the
subsystem/driver. Some maintainers just ignore it completely.
MAINTAINERS now has the "B:" entry to document where maintainers want
bugs reported, and I'd like to see more maintainers document their
preferences there.

Would be great to have bugzilla inform the bug reporters if some
component is likely to be ignored, based on the info in MAINTAINERS, but
I suppose that's a bunch of manual work unlikely to happen.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Daniel Vetter]

On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> What I _would_ like to see is those top maintainers suggest
>> "submaintainer" names. Particularly Davem, since he doesn't tend to
>> want to come to the kernel summit, and being at the top of the list
>> that's a kind of big gaping hole. I guess we haven't had all that many
>> _problems_ within networking, but if we talk maintainership issues,
>> it's certainly a bit odd if it's entirely lacking. We have both core
>> networking and network drivers that both fall under "davem" as far as
>> my pull statistics go.
>
> For ARM, the work also tends to be fairly spread out across many
> people, with few of us being overly important. [I think that while Olof and
> I had similar shares of work in pulling in patches, I ended up in one of
> the top spots because I happened to send more pull requests during
> the last year, and I also did quite a bit of kernel stuff outside of
> arch/arm.]
>
> So while there is no need for having lots of ARM platform maintainers,
> I would like to see some of the people that I interact with that also
> work with a larger number of other maintainers:
>
> - One of the device tree maintainers (Rob Herring, Frank Rowand,
>   Mark Rutland), they inevitably deal with almost all device driver
>   writers at some point
>
> - One of the CLK subsystem maintainers (Michael Turquette,
>   Stephen Boyd), they also interact with a large number of
>   subsystem and platform maintainers, and we have had some
>   disagreements particularly when dealing with three subsystems
>   (clk, arm-soc and a device driver) in one patch series.
>
> - One or two ARM platform maintainers, ideally one that also
>   maintains another kernel subsystem. The platforms with  the most
>   changes are usually sunxi (Maxime Ripard), OMAP (Tony
>   Lindgren), Renesas (Simon Horman), Broadcom (Florian
>   Fainelli), Qualcomm (Andy Gross) and Freescale (Shawn Guo).
>
> - One or two of the ARM32/ARM64 architecture people: Russell
>   King, Catalin Marinas, Will Deacon.

I think discussing arm-soc vs. driver subsystem flows would be good.
Not a personal gripe of mine, but since I seem to be volunteered to
rep drm overall a topic I have to bring in. We have plenty of cross
maintainer patch series and depencies in drm, and the usual way we
handle this is:
- get it reviewed by everyone
- then either get acks from the subsystems (when it's smaller patches,
or well separated from other stuff going on in that subsystem) to
merge it all through one tree (usually the one with the most patches
in the series)
- or create a topic branch and send around cross-subsystem pull requests.

This works rather well, and we have a bunch of cross-subsystem
depencies we handle each month this way with trees outside of drm, not
including the coordination needs within drm among different drm trees.

In arm-soc this seems to not happen, and instead your nice bisectable
patch series which implements an overall feature is split up into a
bunch of trees, which then get forwarded independently. That means the
bisect benefits are out, testing gets harder (either you have your own
integration tree, or try to test linux-next and suffer), and sometimes
even the final patches to enable something or switch drivers for a
platform need to be delayed by an entire release.

Related to this is that there's no single stop-shop for driver
submissions for the arm platform stuff, but it's all split up. Fairly
often that means at least one of the maintainers doesn't like your
face, is on vacation or leave, burried for other reasons, or at least
has slightly different ideas about what color the bikeshed needs to
be. That makes contributions for people who just want to get their
driver for a given platform in a pain.

For non-arm-soc ecosystem drivers things seem a lot more relaxed and
efficient and sensible.

The notable thing is that it's _not_ DT (at least mostly), because Rob
Herring is doing an awesome job getting gpu related DT patches
reviewed and generally acks all of them for merging throught the drm
trees. But even for DT I'm concerned about the bus factor of 1 we
defacto have for gpu drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Laurent Pinchart]

Hi Julia,

On Thursday 20 Apr 2017 07:44:14 Julia Lawall wrote:
> > I'd definitely like to see an "issues that affect casual/occasional
> > contributors" discussion; it wouldn't really fit the maintainer summit,
> > but I like James' suggestion of doing it as part of the attached
> > LinuxCon.
> 
> I would be happy to help with the organization of such a thing.

Given Daniel Vetter's point that no single conference will cover a wide enough 
audience, I've been thinking of trying to gather feedback from a larger 
audience beforehand that could be be used as material for a LinuxCon EU kernel 
track round table session. If that idea gets traction, help will definitely be 
more than welcome.

> > In terms of framing, though, I'd suggest keeping it focused on "what
> > issues have you personally encountered or directly observed", rather
> > than "what random process ideas do you have".  The latter would go
> > downhill very quickly; the former seems much more likely to produce
> > productive feedback on real problems.  (It's less important that they
> > come with potential solutions than that the relevant problems get
> > recorded for subsequent consideration.)
> > 
> > Will the maintainer summit occur *after* the overlapped conference, or
> > *before*?  If after, then it'd be plausible to have a "let's talk about
> > what we heard" session in the maintainer summit.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mauro Carvalho Chehab]

Em Wed, 19 Apr 2017 13:20:37 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

>    1. Since most people agree that these form of notifications are useful,
>       should we have a standard email for it (or at least a list of things
>       which should be in that email, like commit-id, tree, maintainer,
>       mailing list and the version of the kernel it is expected to be
>       pushed for).
>    2. Given that we all run ad-hoc infrastructure to produce these emails,
>       could we get a set of blessed scripts up on kernel.org for all
>       comers so we can use the central infrastructure rather than rolling
>       our own.

I suspect that this very much depends on the way each maintainer handle
patches. For subsystems like media, where we use patchwork, notification
comes for free with the tool.

Thanks,
Mauro

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Greg Kroah-Hartman]

On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote:
> On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > Yeah, I don't think we can do much about distros that intentionally
> > want to stay behind and backport.
> 
> /me looks at https://www.kernel.org/
> 
> 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm
> is based on a five years old release.

That 5 year old kernel is due to Debian's looney release schedule, go
take it up with them :)

> I just think the multitude of longterm kernels are sending a message
> that it's perfectly fine to stay behind. Don't get me wrong, I know why
> they are there, but I still think in the past the focus on encouraging
> to always use the latest stable kernel was stronger.

And how do you suggest that we do that any more than we currently do?
(i.e. I go around and talk to companies all the time about this issue,
did a tour of Asia last month, and will be talking to some US-based
companies next month.)

As you say, you know why they are there, so why is that not a valid
reason in itself?  :)

And you will note (although everyone seems to ignore it), that we are
now only adding 1 new LTS kernel a year, and have been for the past few
years, in order to cut down on the proliferation we had 3-4 years back.

thanks,

greg k-h

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mauro Carvalho Chehab]

Em Wed, 19 Apr 2017 16:36:36 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> On Tue, 18 Apr 2017 18:15:06 -0300
> Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> 
> > There is one particular issue that occurs to me, although I'm not sure
> > if it would fit on the new "maintainer summit" format: it is related
> > to how to group documentation. Also, this is actually Jon's call, but
> > I suspect that he may want to hear comments from the others.  
> 
> I could imagine talking about a few documentation issues, including
> interactions with the rest of the kernel.  Who has responsibility for
> taking docs patches is often not clear, leading to multiple maintainers
> picking them up or conflicts between trees.

I suspect that conflicts are hard to avoid, as often patch series
need to touch both code and Documentation/.

I guess keeping the MAINTAINERS updated to reflect who is responsible
for each file under Documentation is one important step to minimize
conflicts.

Btw, that's one of the reasons why I believe that one book
per subsystem would work better than spreading the subsystem
documentation among several different books: once such book is
added at the main Documentation/index.rst and Documentation/conf.py, 
the subsystem maintainer can take care of all documentation patches
for such book without risking to cause conflicts with other trees.

Thanks,
Mauro

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Arnd Bergmann]

On Thu, Apr 20, 2017 at 10:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> I think discussing arm-soc vs. driver subsystem flows would be good.
> Not a personal gripe of mine, but since I seem to be volunteered to
> rep drm overall a topic I have to bring in. We have plenty of cross
> maintainer patch series and depencies in drm, and the usual way we
> handle this is:
> - get it reviewed by everyone
> - then either get acks from the subsystems (when it's smaller patches,
> or well separated from other stuff going on in that subsystem) to
> merge it all through one tree (usually the one with the most patches
> in the series)
> - or create a topic branch and send around cross-subsystem pull requests.
>
> This works rather well, and we have a bunch of cross-subsystem
> depencies we handle each month this way with trees outside of drm, not
> including the coordination needs within drm among different drm trees.
>
> In arm-soc this seems to not happen, and instead your nice bisectable
> patch series which implements an overall feature is split up into a
> bunch of trees, which then get forwarded independently. That means the
> bisect benefits are out, testing gets harder (either you have your own
> integration tree, or try to test linux-next and suffer), and sometimes
> even the final patches to enable something or switch drivers for a
> platform need to be delayed by an entire release.

Do you know of a specific example where this happened? We try
to take a lot of care to ensure that each of the branches is bisectable,
so it sounds like we (or our downstream developers) were missing
something in the QA testing if this failed repeatedly.

When I'm aware of a change that requires cross-tree coordination
(e.g. a Kconfig symbol gets renamed, or a DT binding changes
in an incompatible way), we usually try to come up with a way to
do the change differently (e.g. add have multiple Kconfig symbols
with the same meaning for a release or two, or find a way to
make the binding backwards compatible after all), but we also
frequently give Acks for merging stuff in arch/arm, or have a shared
tree that gets merged through both a driver subsystem and one
of our branches.

> Related to this is that there's no single stop-shop for driver
> submissions for the arm platform stuff, but it's all split up. Fairly
> often that means at least one of the maintainers doesn't like your
> face, is on vacation or leave, burried for other reasons, or at least
> has slightly different ideas about what color the bikeshed needs to
> be. That makes contributions for people who just want to get their
> driver for a given platform in a pain.

This is in a large part by design: we used to have a problem with
dozens of platforms in arch/arm/mach-* doing the same things
slightly differently, each of them being controlled only by a single
platform maintainer. We have over time introduced many separate
subsystems (irqchip, rtc, gpio, pinctrl, iommu, clk, timer, led, pci,
cpufreq, cpuidle, pwm, dmaengine, phy, regulator, memory,
nvmem, thermal, hwspinlock, mailbox, reset, and probably a few
others), and moved code out of our responsibility into those
subsystems that are maintained independently.

The subsystem maintainers have a much better understanding
of how things work in their domain across all the platforms, so
we get better review than we had in the 2.6 days when this all
fell upon a single architecture or platform maintainer. You still
typically have to get new changes approved by both a platform
maintainer (for your SoC) as well as the subsystem maintainer,
and I consider that a good idea. The price for it however is that
 anyone working on a single platform has to deal with a
multitude of git trees, and things become harder at the point
 where they interact, especially when you migrate a platform
from old-style board files to devicetree.

Fortunately these days, the vast majority of changes we deal
with are purely additions of new drivers or features, so there
are rarely any actual cross-tree dependencies or conflicts any
more: The only things that we merge through arm-soc most
of the time are defconfig additions, dts file changes and
sometimes new Kconfig symbols for new platforms, and all
of them can come in any order without causing regressions.

      Arnd

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jani Nikula]

On Thu, 20 Apr 2017, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote:
>> On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> > Yeah, I don't think we can do much about distros that intentionally
>> > want to stay behind and backport.
>> 
>> /me looks at https://www.kernel.org/
>> 
>> 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm
>> is based on a five years old release.
>
> That 5 year old kernel is due to Debian's looney release schedule, go
> take it up with them :)
>
>> I just think the multitude of longterm kernels are sending a message
>> that it's perfectly fine to stay behind. Don't get me wrong, I know why
>> they are there, but I still think in the past the focus on encouraging
>> to always use the latest stable kernel was stronger.
>
> And how do you suggest that we do that any more than we currently do?
> (i.e. I go around and talk to companies all the time about this issue,
> did a tour of Asia last month, and will be talking to some US-based
> companies next month.)
>
> As you say, you know why they are there, so why is that not a valid
> reason in itself?  :)

Well, I'm just saying it's a double edged sword. Accommodating the
longterms says it's okay to rely on them, but then you go around the
world telling people they shouldn't do that anyway. It's a tradeoff.

Or maybe you just like traveling? ;)

> And you will note (although everyone seems to ignore it), that we are
> now only adding 1 new LTS kernel a year, and have been for the past few
> years, in order to cut down on the proliferation we had 3-4 years back.

I think that's a step in the right direction. How about having a shorter
lifetime too, despite "longterm"? Of course that would conflict with
what the distros are doing, and this may not be a popular view, but I'm
wondering if it's overall a net positive to give an appearance of
kernel.org endorsing all these ancient kernels?


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Thu, Apr 20, 2017 at 11:31:31AM +0300, Jani Nikula wrote:

> subsystem/driver. Some maintainers just ignore it completely.
> MAINTAINERS now has the "B:" entry to document where maintainers want
> bugs reported, and I'd like to see more maintainers document their
> preferences there.

I'd expect that a large proportion of people are assuming the default is
to report it to the list.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jani Nikula]

On Thu, 20 Apr 2017, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Apr 20, 2017 at 11:31:31AM +0300, Jani Nikula wrote:
>
>> subsystem/driver. Some maintainers just ignore it completely.
>> MAINTAINERS now has the "B:" entry to document where maintainers want
>> bugs reported, and I'd like to see more maintainers document their
>> preferences there.
>
> I'd expect that a large proportion of people are assuming the default is
> to report it to the list.

Seems like the right thing to do is to better document the expectations
in Documentation/admin-guide/reporting-bugs.rst, and then point
MAINTAINERS and, more importantly, [1] and [2] to that.

BR,
Jani.


[1] https://bugzilla.kernel.org/page.cgi?id=faq.html
[2] https://bugzilla.kernel.org/page.cgi?id=bug-writing.html

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Greg Kroah-Hartman]

On Thu, Apr 20, 2017 at 03:22:26PM +0300, Jani Nikula wrote:
> On Thu, 20 Apr 2017, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote:
> >> On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >> > Yeah, I don't think we can do much about distros that intentionally
> >> > want to stay behind and backport.
> >> 
> >> /me looks at https://www.kernel.org/
> >> 
> >> 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm
> >> is based on a five years old release.
> >
> > That 5 year old kernel is due to Debian's looney release schedule, go
> > take it up with them :)
> >
> >> I just think the multitude of longterm kernels are sending a message
> >> that it's perfectly fine to stay behind. Don't get me wrong, I know why
> >> they are there, but I still think in the past the focus on encouraging
> >> to always use the latest stable kernel was stronger.
> >
> > And how do you suggest that we do that any more than we currently do?
> > (i.e. I go around and talk to companies all the time about this issue,
> > did a tour of Asia last month, and will be talking to some US-based
> > companies next month.)
> >
> > As you say, you know why they are there, so why is that not a valid
> > reason in itself?  :)
> 
> Well, I'm just saying it's a double edged sword. Accommodating the
> longterms says it's okay to rely on them, but then you go around the
> world telling people they shouldn't do that anyway. It's a tradeoff.
> 
> Or maybe you just like traveling? ;)

No, I don't like traveling :)

And I tell people to rely on these kernels instead of trying to do it on
their own, as they always get it wrong when they do not use a longterm
kernel (they were going to only stick with one kernel release anyway).

I tell people to pick the latest LTS for their product, and use that,
and update constantly.  Even better, if their SoC vendor doesn't add 2-3
million lines of code to their kernel, use the latest kernel.org release
from Linus.  But SoC vendors who don't do that are very few these days,
so lots of my work is to try to cut that huge diff down.

But getting rid of that diff is going to take a long time, or major
customer disatisfaction/change, which I'm also trying to force.
Otherwise the SoC vendor doesn't really care (as is evident by the 3
million line diff...)

> > And you will note (although everyone seems to ignore it), that we are
> > now only adding 1 new LTS kernel a year, and have been for the past few
> > years, in order to cut down on the proliferation we had 3-4 years back.
> 
> I think that's a step in the right direction. How about having a shorter
> lifetime too, despite "longterm"? Of course that would conflict with
> what the distros are doing, and this may not be a popular view, but I'm
> wondering if it's overall a net positive to give an appearance of
> kernel.org endorsing all these ancient kernels?

Why is longer lifetimes bad?  If the developer wants to do the work,
that's fine.  For lots of users, they have to stay at a specific kernel
release due to (again) their horrid SoC vendor.  Heck, I've even offered
to forward port some SoC trees to newer kernels, and had the SoC vendor
turn me down because they don't want anyone to get the idea that it
would even be possible to do!

So some users are stuck at these older kernels, supporting them with a
stream of good bugfixes is essential to ensure that their devices are
secure and work well over time.  That's a valuable thing for them and a
good reason for them to use Linux.

It's not a black/white issue here, as you well know, it's a large
ecosystem full of different groups pulling different ways.  I'll always
push for people to use newer kernels, and age-out older ones, and the
new hardware treadmill supports that quite well.  Combined with
educating and helping companies merge stuff upstream, it can get better,
and is.  Look at how bad it used to be just 3 years ago :)

thanks,

greg k-h

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Thu, 2017-04-20 at 10:26 +0200, Daniel Vetter wrote:
> On Wed, Apr 19, 2017 at 9:55 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Isn't it easy?  The Maintainers summit is going to be part of a 
> > larger kernel track within LinuxCon EU  (not that everyone plans on
> > staying on, of course, but several will be).  Just put the bitch at
> > Maintainers session in that as a round table, so any attendee of 
> > LinuxCon EU can come and complain if they want to.
> 
> I don't think it's that easy. I guess due to the "interesting" stuff
> we're doing in drm I get to hear some of the frustration stories from
> leaf contributors. Picking a conference means you exclude folks who
> won't go there (and Linux is so huge that there's simply no single
> conference that would cover it all),

Well, that's a reason for never doing anything at a conference, yes. 
 However, the other way to look at it is that if the Maintainer summit
rotates between US, EU and Asia and is allied to a tech conference in
each, then we have a continent-local venue covering most of the world.

So the argument isn't that this is a perfect solution, but that it's a
good one because it gives people the opportunity to come and give
feedback without having to have an invitation to the Maintainer summit.

> but more important a common theme I'm hearing is that frustrated 
> folks don't want to speak up in public, because if they piss of their 
> maintainer, their problems just get worse.

So perhaps they might turn up to give it privately.

>  On the other hand they lack the power and influence to fix
> anything, so there's very little upside to speaking up about issues.
> The usual solution seems to eventually just quietly abandon upstream,
> or at least the particular subsystem.

Empowerment is about giving people opportunities.  I find most people
take them.  The fact that a few people may not avail themselves isn't a
good reason for not trying.

> The other thing is that because Linuxcon has such a wide audience you
> might just get the peanut gallery kernel bashing from bystanders, not
> feedback from actual (or at least potential) contributors.

On that reasoning, we should abandon democracy immediately.

James

> Still worth trying I guess, but I wouldn't be surprised if there's 
> not much coming out of such a feedback session.
> -Daniel

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Wed, 2017-04-19 at 22:23 -0700, Christoph Hellwig wrote:
> On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote:
> > There is one piece of feedback I guess I can share right away on 
> > this -- I've heard so many complaints that Doc<tab>/kern<tab>
> > -par<tab> completion stopped to yield Documentation/kernel
> > -parameters.txt that it's not really funny any more :)
> 
> Yeah.  All this moving files around really messed up my workflows.
> Let's see if I'll be able to adjust eventually.

Seconded.  The one that trips me up the most is the uapi one ... I
always forget that include/linux/X.h might have an
include/uapi/linux/X.h counterpart which is where the structure I'm
looking for actually is.

I think it's worth discussing this.  We accept a lot of patches because
we can and because the change looks innocuous enough, but which don't
actually have a tangible user visible benefit.  Should we actually have
a net benefit threshold test we apply?

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Daniel Vetter]

On Thu, Apr 20, 2017 at 1:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Apr 20, 2017 at 10:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> I think discussing arm-soc vs. driver subsystem flows would be good.
>> Not a personal gripe of mine, but since I seem to be volunteered to
>> rep drm overall a topic I have to bring in. We have plenty of cross
>> maintainer patch series and depencies in drm, and the usual way we
>> handle this is:
>> - get it reviewed by everyone
>> - then either get acks from the subsystems (when it's smaller patches,
>> or well separated from other stuff going on in that subsystem) to
>> merge it all through one tree (usually the one with the most patches
>> in the series)
>> - or create a topic branch and send around cross-subsystem pull requests.
>>
>> This works rather well, and we have a bunch of cross-subsystem
>> depencies we handle each month this way with trees outside of drm, not
>> including the coordination needs within drm among different drm trees.
>>
>> In arm-soc this seems to not happen, and instead your nice bisectable
>> patch series which implements an overall feature is split up into a
>> bunch of trees, which then get forwarded independently. That means the
>> bisect benefits are out, testing gets harder (either you have your own
>> integration tree, or try to test linux-next and suffer), and sometimes
>> even the final patches to enable something or switch drivers for a
>> platform need to be delayed by an entire release.
>
> Do you know of a specific example where this happened? We try
> to take a lot of care to ensure that each of the branches is bisectable,
> so it sounds like we (or our downstream developers) were missing
> something in the QA testing if this failed repeatedly.
>
> When I'm aware of a change that requires cross-tree coordination
> (e.g. a Kconfig symbol gets renamed, or a DT binding changes
> in an incompatible way), we usually try to come up with a way to
> do the change differently (e.g. add have multiple Kconfig symbols
> with the same meaning for a release or two, or find a way to
> make the binding backwards compatible after all), but we also
> frequently give Acks for merging stuff in arch/arm, or have a shared
> tree that gets merged through both a driver subsystem and one
> of our branches.

Not "broken bisecting" as in if you bisect you might hit a broken
configuration, but reduced usefulness for figuring out bugs. If a
bigger feature or change in driver that also comes with some
clk/irqchip/whatever changes, or an entire rewrite, then I've heard of
examples where the splitting across trees meant that your bisect would
end up in one of the merge commits (whichever is the last one that
adds the missing piece) instead of somewhere in the middle like if the
original patch series would have landed as linear history in a topic
branch.

Might just be good to chat a bit about when exactly a topic branch is
called for, and when exactly merging through each separate tree is
better. I get a bit the feeling that merging through separate trees is
done to make sure platforms use all the infrastructure correctly
(which is the topic below), but it seems like DT managed to get there
without merging things stricly only through a DT tree.

>> Related to this is that there's no single stop-shop for driver
>> submissions for the arm platform stuff, but it's all split up. Fairly
>> often that means at least one of the maintainers doesn't like your
>> face, is on vacation or leave, burried for other reasons, or at least
>> has slightly different ideas about what color the bikeshed needs to
>> be. That makes contributions for people who just want to get their
>> driver for a given platform in a pain.
>
> This is in a large part by design: we used to have a problem with
> dozens of platforms in arch/arm/mach-* doing the same things
> slightly differently, each of them being controlled only by a single
> platform maintainer. We have over time introduced many separate
> subsystems (irqchip, rtc, gpio, pinctrl, iommu, clk, timer, led, pci,
> cpufreq, cpuidle, pwm, dmaengine, phy, regulator, memory,
> nvmem, thermal, hwspinlock, mailbox, reset, and probably a few
> others), and moved code out of our responsibility into those
> subsystems that are maintained independently.
>
> The subsystem maintainers have a much better understanding
> of how things work in their domain across all the platforms, so
> we get better review than we had in the 2.6 days when this all
> fell upon a single architecture or platform maintainer. You still
> typically have to get new changes approved by both a platform
> maintainer (for your SoC) as well as the subsystem maintainer,
> and I consider that a good idea. The price for it however is that
>  anyone working on a single platform has to deal with a
> multitude of git trees, and things become harder at the point
>  where they interact, especially when you migrate a platform
> from old-style board files to devicetree.
>
> Fortunately these days, the vast majority of changes we deal
> with are purely additions of new drivers or features, so there
> are rarely any actual cross-tree dependencies or conflicts any
> more: The only things that we merge through arm-soc most
> of the time are defconfig additions, dts file changes and
> sometimes new Kconfig symbols for new platforms, and all
> of them can come in any order without causing regressions.

Just to clarify: I'm very impressed with all the infrastructure the
arm-soc folks manged to pull off, and I understand why you have them
all and how it works. But having bigger groups for bus factor reasons
and making it easier for totally new contributions to not get
completely lost and leave in frustration might be good. DRM is also
fairly big nowadays, with piles of helpers and libraries for different
things (not quite at the level of arm-soc yet), but we try to give new
driver submissions one person who handles the entire thing, and pulls
in acks from specific experts as needed. Still needs some working out
and maybe formalizing the process more (atm it's mostly coordination
over irc), but with group maintiners for all areas and load balancing
between them that seems to work fairly well. While still making sure
that new drivers use all the latest helpers and best practices (we add
them constantly, so almost always something that could be simplified
by using a new thing just merge 1-2 months ago). And sharing knowledge
about all these things amongst maintainers and reviewers.

And yeah, rewriting an entire platform from the old to the new model
is a different beast on its own, this here is just from the pov of
submitting individual drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Alexey Dobriyan]

On Thu, Apr 20, 2017 at 4:33 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2017-04-19 at 22:23 -0700, Christoph Hellwig wrote:
>> On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote:
>> > There is one piece of feedback I guess I can share right away on
>> > this -- I've heard so many complaints that Doc<tab>/kern<tab>
>> > -par<tab> completion stopped to yield Documentation/kernel
>> > -parameters.txt that it's not really funny any more :)
>>
>> Yeah.  All this moving files around really messed up my workflows.
>> Let's see if I'll be able to adjust eventually.
>
> Seconded.  The one that trips me up the most is the uapi one ... I
> always forget that include/linux/X.h might have an
> include/uapi/linux/X.h counterpart which is where the structure I'm
> looking for actually is.

Let's not forget x86 master system call definition table movement.
Just as finger memory is developed they move it again.

And of course drivers/net directory structure explosion
where drivers/net/e<TAB> doesn't work.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jonathan Corbet]

On Thu, 20 Apr 2017 06:33:58 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> I think it's worth discussing this.  We accept a lot of patches because
> we can and because the change looks innocuous enough, but which don't
> actually have a tangible user visible benefit.  Should we actually have
> a net benefit threshold test we apply?

With regard to the documentation patches, the intended tangible
user-visible benefit is to turn a jumbled mess of a documentation
directory into a set of coherent manuals that are aimed at and readily
accessible to our different audiences (kernel developers, system
administrators, application developers, etc. as appropriate).

If we had always tossed the SCSI subsystem source into a single directory
along with SCTP, user-mode Linux, perf, half of the TTY drivers, and all
filesystems written before the second Bush administration, it would
certainly make for easier muscle-memory access for those of us who think
back nostalgically to installing from floppies.  But for some strange
reason we don't do that.

When code needs refactoring, we do so - when, as you said, there is a
tangible benefit.  The same applies to directory organization.  Though
that may not apply to Documentation/ since we never really got around to
an original factoring to refactor.

Anyway, you can see why I raised the issue.  I think that this process is
improving the documentation, making it more accessible, and making more
people interested in improving it.  But I have my hands plenty full of
other things and, if this work is really swimming against the current, it
would be good to know.

jon

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Thu, Apr 20, 2017 at 12:59:33PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote:

> > 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm
> > is based on a five years old release.

> That 5 year old kernel is due to Debian's looney release schedule, go
> take it up with them :)

A combination of release schedule and lack of desire to update kernels
mid release.

> > I just think the multitude of longterm kernels are sending a message
> > that it's perfectly fine to stay behind. Don't get me wrong, I know why
> > they are there, but I still think in the past the focus on encouraging
> > to always use the latest stable kernel was stronger.

> And how do you suggest that we do that any more than we currently do?
> (i.e. I go around and talk to companies all the time about this issue,
> did a tour of Asia last month, and will be talking to some US-based
> companies next month.)

Honestly at this point I'm not even sure how much of an issue it is with
the idea that people should update - as far as I can tell the main
problems are similar to the things keeping the enterprise distros from
upgrading, not wanting to introduce large change in something that's
already production.  I'm not sure we have any good answers there really
other than gradually getting through the technical debt with upstreaming.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Ingo Molnar]

* Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Thu, Apr 20, 2017 at 4:33 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Wed, 2017-04-19 at 22:23 -0700, Christoph Hellwig wrote:
> >> On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote:
> >> > There is one piece of feedback I guess I can share right away on
> >> > this -- I've heard so many complaints that Doc<tab>/kern<tab>
> >> > -par<tab> completion stopped to yield Documentation/kernel
> >> > -parameters.txt that it's not really funny any more :)
> >>
> >> Yeah.  All this moving files around really messed up my workflows.
> >> Let's see if I'll be able to adjust eventually.
> >
> > Seconded.  The one that trips me up the most is the uapi one ... I
> > always forget that include/linux/X.h might have an
> > include/uapi/linux/X.h counterpart which is where the structure I'm
> > looking for actually is.
> 
> Let's not forget x86 master system call definition table movement.
> Just as finger memory is developed they move it again.

If you mean arch/x86/entry/syscalls/syscall_64.tbl, it was originally introduced 6 
years ago as arch/x86/syscalls/syscall_64.tbl and moved _once_ to 
arch/x86/entry/syscalls/syscall_64.tbl.

Same for arch/x86/syscalls/syscall_32.tbl, so I'm not sure what you are talking 
about here...

Thanks,

	Ingo

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Thu, 2017-04-20 at 08:47 -0600, Jonathan Corbet wrote:
> On Thu, 20 Apr 2017 06:33:58 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > I think it's worth discussing this.  We accept a lot of patches 
> > because we can and because the change looks innocuous enough, but 
> > which don't actually have a tangible user visible benefit.  Should 
> > we actually have a net benefit threshold test we apply?
> 
> With regard to the documentation patches, the intended tangible
> user-visible benefit is to turn a jumbled mess of a documentation
> directory into a set of coherent manuals that are aimed at and 
> readily accessible to our different audiences (kernel developers, 
> system administrators, application developers, etc. as appropriate).

I'm not saying don't do it, I'm staying understand the cost vs benefit
before doing it.

> If we had always tossed the SCSI subsystem source into a single
> directory along with SCTP, user-mode Linux, perf, half of the TTY
> drivers, and all filesystems written before the second Bush
> administration, it would certainly make for easier muscle-memory
> access for those of us who think back nostalgically to installing
> from floppies.  But for some strange reason we don't do that.

I'm also not saying do a flat tree.  I am saying putting things in the
right place ab initio and then having a reasonably high barrier for
moving it has value.

> When code needs refactoring, we do so - when, as you said, there is a
> tangible benefit.

Right, I think we've been quite good at the refactor net benefit tests
... mostly, I think, because refactoring is a lot of work and a lot of
argument to get it accepted so people think very carefully before they
do it.  It is self supplying on the net benefit test ... I think we
have certain actions which aren't so self supplying in this regard.

Ideally, everything would be like this: the level of difficulty in
doing something would be directly proportional to the amount of thought
you should put into it.  However, the world is not mostly structured
like this hence the question about a net benefit test which would raise
the barrier.

>   The same applies to directory organization.  Though that may not
> apply to Documentation/ since we never really got around
> to an original factoring to refactor.
> 
> Anyway, you can see why I raised the issue.  I think that this 
> process is improving the documentation, making it more accessible, 
> and making more people interested in improving it.  But I have my 
> hands plenty full of other things and, if this work is really 
> swimming against the current, it would be good to know.

I'd prefer it if the summit didn't become a star chamber where we re
-run past decisions.  However, I think the process question of how (or
whether) we should add process barriers for certain actions is a useful
one.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Dan Williams]

On Wed, Apr 19, 2017 at 1:20 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote:
[..]
> Finally, since Daniel Vetter brought it up, having CI tests is seen as
> a requirement for most git automation nowadays.  I tend to see 0day
> plus my user base as the CI infrastructure but we should discuss
> whether this is adequate.  I think 0day and linux-next pick up most
> merge and generic test issues, and no-one has all the hardware to run a
> true driver CI, so perhaps this is the best we can do, but we should at
> least discuss whether we want to try to do better.

I think we can do better with approaches like cmock [1] to go attack
code paths that would otherwise require specific hardware. The pain
points I see around testing are, how to discover and run available
tests for a given subsystem, and how to determine a "clean" run. For
example, xfstests depend on not only the kernel, but utilities as
well. Tracking all the moving pieces, tests, kernel and utilities is a
non-trivial amount of overhead.

[1]: http://www.throwtheswitch.org/cmock/

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Tue, Apr 18, 2017 at 11:39:22PM +0200, Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 10:56 PM, Linus Torvalds

> > Side note: people should think about various infrastructure/testing
> > people too  So kernel.org, but also things like zero-day etc test
> > labs.

For kernelci.org the kernel people involved are Kevin Hilman and myself,
mainly Kevin.  

There's also some work on automation of actual test running going on in
Linaro intended to end up fulfiling a similar role to the various
build/boot bots which should be in a state to talk about usefully by
October but I don't want to overpromise.  I'll definitely be able to
talk about some of the experience with getting things up and running by
then.

> Hm, we're trying to build up a much more ambitious CI here for drm and
> intel specifically, but nothing all that interesting yet relevant
> beyond drm. What could be interesting (but not for the discussion
> session, more for the general track) is getting our userspace CI team
> to explain what they do. Except that it runs in userspace the gl

I'm wondering if we should be trying to ge a miniconf together for this
stuff, there's a reasonable number of people attacking kernel QA from
various angles and there's probably a lot to be gained from sharing
ideas and experiences.

> A hw testing bof thing for different (driver) subsystems to compare
> notes might be good, but I'm not sure that'd be useful for the group
> discussions really. Probably more talking to the audience than what
> you're aiming for.

I think there's a useful conversation to be had there if we do have a
good selection of downstream users in the room, not just about hardware
testing but more generally about what we're doing upstream around test
and how that's translating to our downstreams.  How do we make sure that
people who are either downstream users or just interested in general
kernel testing find out about tests we're using upstream, how to use
them and so on?  Are the tests we're using useful for them as well as
the developers?

Ideally testing could be another way to open up interaction with people
who haven't been working upstream so much, or if nothing else help
raise the quality of out of tree code, but at the minute it seems like
we have a discoverability problem.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Thu, Apr 20, 2017 at 10:53:54AM +0200, Daniel Vetter wrote:

> Related to this is that there's no single stop-shop for driver
> submissions for the arm platform stuff, but it's all split up. Fairly
> often that means at least one of the maintainers doesn't like your
> face, is on vacation or leave, burried for other reasons, or at least
> has slightly different ideas about what color the bikeshed needs to
> be. That makes contributions for people who just want to get their
> driver for a given platform in a pain.

> For non-arm-soc ecosystem drivers things seem a lot more relaxed and
> efficient and sensible.

I really think this is more of a cross subsystem issue than an ARM issue
- I'm seeing it come up just as much with x86 stuff these days as ARM
(more so at the minute, though I think that's just a bit of learning
that's going on).  x86 has historically been simpler hardware with less
interaction between blocks that triggers cross subsystem issues but
that's becoming less and less the case for the laptops.

Most of what I'm seeing these days goes pretty smoothly, and we're
reasonably well decoupled for the common cases so things can make
progress even if one bit does end up getting stuck.  AFAICT the main
issues are the normal maintainer scaling problems.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Rafael J. Wysocki]

Hi Linus,

On Tuesday, April 18, 2017 11:59:37 AM Linus Torvalds wrote:
> The kernel summit is apparently in October, and I promised last year
> to at least get the ball rolling with the people *I* would like to
> see.

[cut]

> So the other way to split it up is by "maintenance area", ie we have
> 
>  - architectures
> 
>    Pretty much covered by x86, arm, powerpc, and those architectures
> should talk about who within the group would attend.
> 
>  - drivers
> 
>    Obviously we have Greg overall, with drm and rdma because of issues.
> 
>    An example here is that Christoph doesn't show up because I don't
> generally pull from him, but he's been all over and often crosses
> multiple driver subsystems, and has been involved in rdma too, so I'd
> add him just for that.
> 
>    Some driver subsystems may be huge (eg media and sound), but I
> don't know if they have issues. Mauro/Takashi?
> 
>  - filesystems
> 
>    Al, XSF and ext4 stand out by size (XFS is mostly Dave Chinner due
> to me going by past year, but is obviously Darrick Wong right now).
> 
>  - core stuff.
> 
>    We've got Andrew, and I'd add Tejun from the list, with others
> possible? Maintenance issues here are actually sometimes contentious
> even if the core kernel is fairly small.
> 
>  - security stuff
> 
>    Luto, Kees?
> 
>  - particular pain points. Any not mentioned?
> 
>  - other?

I'm not sure if PM can be regarded as "core stuff" or "drivers", but it just
tends to be spread all over, so I guess it's sort of unusual.  It interacts
with pretty much everything, though, so maybe should be represented? ;-)

Also I have a couple of pain points, although to be entirely honest I don't
really think about them on a daily basis, so you can count me as relatively
happy in that respect. :-)

But since you are asking, one thing that bothers me is that I seem to be the
only person on the planet sufficiently familiar with some pieces of kernel code
to be able to fix issues in them without an extensive research.  At least
nobody else openly admits to be familiar with that code too.

I guess the reason why is that I tend to take care of code rarely looked
at by anyone else and people look at it mostly if it causes problems visible
to them to happen this way or another.  Then, once the problem at hand goes
away, they go back to the other stuff which presumably is more interesting to
them.  I often end up fixing those issues myself, just because I'm familiar
with the code in question, and so this goes on.

That's not a particularly comfortable situation to be in for various reasons,
but I have to admit that I don't really know how to address it generally and
long-term.  It would boil down to finding somebody who would be sufficiently
interested in that code to understand all of it and would stay on the project
for long enough, but that's sort of hard.

[Besides, there are pieces of kernel code familiar to no one with a valid
e-mail address (like some cpufreq drivers for an easy example) and  there
is barely any hardware they can be tested on after modifications (which
sometimes are necessary due to framework changes etc).]

It also is hard to make people review code changes in a meaningful way,
especially if the code being modified is not what they work on routinely.
That's entirely understandable to me, because if that's not part of their job,
it becomes tedious unpaid work done voluntarily for the better good of
everyone, so to speak, and totally unrewarding in many cases.

That is not to say that code review doesn't happen.  It happens, but not
as much as to make me entirely happy.  At the same time I don't really think it
would be good to make code review mandatory overall.  In fact, I'm not sure if
doing that would improve things at all.  I wonder, however, if it is possible
to make code review generally more rewarding (or attractive?) somehow.

Finally, there is quite a bit of code in various vendor or product trees and
similar that's never submitted to us and we don't even know about it, but it
is shipped in products.  Also, there are drivers available as source code that
can be downloaded from vendor web sites, but are never submitted for
merging.

This clearly means to me that there's not enough incentive for people to submit
their code and I wonder if there's anything we can do to address that.  Moreover,
I actually would prefer problems or use cases to be discussed with us before
any code is implemented, but quite evidently there's no incentive for that
either.

> I'd like the maintainership summit list to be fairly small. Not even
> 50 people. Maybe 30. A group that can actually sit in a room for half
> a day and talk to each other about the issues they have rather than
> being talked to. And talk literally about *process* issues, not about
> any particular technical issues within whatever subsystem. Bring up
> peeves or wishes for actual process improvements?
> 
> Comments? People who should be involved? Or people who don't have any
> particular issues and want to not be involved?

As for who should be involved, IMO if that's going to be a "maintainer summit", the
majority of people in the room should be maintainers.  I would go for proportions
like 2/3 maintainers and 1/3 distro/infrastructure/testing/users/etc with the
total number somewhere between 36 and 45.

Cheers,
Rafael

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Alexandre Belloni]

On 20/04/2017 at 11:31:31 +0300, Jani Nikula wrote:
> On Wed, 19 Apr 2017, Laura Abbott <labbott@redhat.com> wrote:
> > I brought up bug reporting last year and I still consider that to be
> > an issue this year. A good example is
> > https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really
> > make progress until I sent out a separate e-mail thread summarizing
> > the bisections people did.
> 
> The service level at https://bugzilla.kernel.org heavily depends on the
> subsystem/driver. Some maintainers just ignore it completely.
> MAINTAINERS now has the "B:" entry to document where maintainers want
> bugs reported, and I'd like to see more maintainers document their
> preferences there.
> 

I think that addition has not been noticed by many maintainers and that
is actually one of my pain point.
I feel like that kind of changes that are relevant for all the
maintainers are not advertised enough but I also realize you probably
don't want to Cc: every maintainer on your patch.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Alexandre Belloni]

On 20/04/2017 at 07:24:13 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 19 Apr 2017 13:20:37 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
> >    1. Since most people agree that these form of notifications are useful,
> >       should we have a standard email for it (or at least a list of things
> >       which should be in that email, like commit-id, tree, maintainer,
> >       mailing list and the version of the kernel it is expected to be
> >       pushed for).
> >    2. Given that we all run ad-hoc infrastructure to produce these emails,
> >       could we get a set of blessed scripts up on kernel.org for all
> >       comers so we can use the central infrastructure rather than rolling
> >       our own.
> 
> I suspect that this very much depends on the way each maintainer handle
> patches. For subsystems like media, where we use patchwork, notification
> comes for free with the tool.
> 

I think patchwork notifications are sent only to people with a patchwork
account so this is not enough for subsystems with a lot of drive-by
contributors.


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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Julia Lawall]

On Fri, 21 Apr 2017, Alexandre Belloni wrote:

> On 20/04/2017 at 07:24:13 -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 19 Apr 2017 13:20:37 -0700
> > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> >
> > >    1. Since most people agree that these form of notifications are useful,
> > >       should we have a standard email for it (or at least a list of things
> > >       which should be in that email, like commit-id, tree, maintainer,
> > >       mailing list and the version of the kernel it is expected to be
> > >       pushed for).
> > >    2. Given that we all run ad-hoc infrastructure to produce these emails,
> > >       could we get a set of blessed scripts up on kernel.org for all
> > >       comers so we can use the central infrastructure rather than rolling
> > >       our own.
> >
> > I suspect that this very much depends on the way each maintainer handle
> > patches. For subsystems like media, where we use patchwork, notification
> > comes for free with the tool.
> >
>
> I think patchwork notifications are sent only to people with a patchwork
> account so this is not enough for subsystems with a lot of drive-by
> contributors.

I receive such notifications and don't have an account, as far as I know.

julia

>
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Wolfram Sang]

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


> I think patchwork notifications are sent only to people with a patchwork
> account so this is not enough for subsystems with a lot of drive-by
> contributors.

It can be configured to send emails to everyone. But you need to ask the
admin to do that. Jeremy did that for me on ozlabs with the i2c-list.


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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Michael Ellerman]

Mauro Carvalho Chehab <mchehab@s-opensource.com> writes:

> Em Wed, 19 Apr 2017 13:20:37 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
>
>>    1. Since most people agree that these form of notifications are useful,
>>       should we have a standard email for it (or at least a list of things
>>       which should be in that email, like commit-id, tree, maintainer,
>>       mailing list and the version of the kernel it is expected to be
>>       pushed for).
>>    2. Given that we all run ad-hoc infrastructure to produce these emails,
>>       could we get a set of blessed scripts up on kernel.org for all
>>       comers so we can use the central infrastructure rather than rolling
>>       our own.
>
> I suspect that this very much depends on the way each maintainer handle
> patches. For subsystems like media, where we use patchwork, notification
> comes for free with the tool.

AFAIK patchwork can only notify the submitter of the patch, which is OK,
but I think it's preferable if the notification goes to the recipient
list of the original mail.

For example it's quite handy to know when another maintainer has merged
a patch, so you don't merge it too, or wonder if you should.

cheers

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Alexandre Belloni]

Hi,

On 19/04/2017 at 22:26:34 +0200, Arnd Bergmann wrote:
> On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> 
> > What I _would_ like to see is those top maintainers suggest
> > "submaintainer" names. Particularly Davem, since he doesn't tend to
> > want to come to the kernel summit, and being at the top of the list
> > that's a kind of big gaping hole. I guess we haven't had all that many
> > _problems_ within networking, but if we talk maintainership issues,
> > it's certainly a bit odd if it's entirely lacking. We have both core
> > networking and network drivers that both fall under "davem" as far as
> > my pull statistics go.
> 
> For ARM, the work also tends to be fairly spread out across many
> people, with few of us being overly important. [I think that while Olof and
> I had similar shares of work in pulling in patches, I ended up in one of
> the top spots because I happened to send more pull requests during
> the last year, and I also did quite a bit of kernel stuff outside of
> arch/arm.]
> 
> So while there is no need for having lots of ARM platform maintainers,
> I would like to see some of the people that I interact with that also
> work with a larger number of other maintainers:
> 
> - One of the device tree maintainers (Rob Herring, Frank Rowand,
>   Mark Rutland), they inevitably deal with almost all device driver
>   writers at some point
> 
> - One of the CLK subsystem maintainers (Michael Turquette,
>   Stephen Boyd), they also interact with a large number of
>   subsystem and platform maintainers, and we have had some
>   disagreements particularly when dealing with three subsystems
>   (clk, arm-soc and a device driver) in one patch series.
> 
> - One or two ARM platform maintainers, ideally one that also
>   maintains another kernel subsystem.

I would fit that description, although mach-at91 is so small now that we
have very few issues with arm-soc. However, I have two particular
points:
 - what to do which the many coccinelle generated patches that are sent.
I find that many are not tested, don't really improve readability and
are sometimes harmful. I used to apply them, I don't anymore because
they sometimes take too much time to review for absolutely zero benefit.
The main category is the switch to devm_ functions in old drivers that
are already handling error case pretty well.
 - my subsystem (RTC) is pretty dependant on two bus subsystems (I2C and
   SPI). Sometimes, it would be good to be included in discussions that
will affect many drivers instead of finding that they have to be patched
after the fact. I'm mainly thinking about recent work from Javier
regarding OF matching in i2c. The main drawback of including more people
is probably the bikeshedding that will ensue but I feel like more
coordination would have been necessary to make Javier's life a bit
easier.

>                                       The platforms with  the most
>   changes are usually sunxi (Maxime Ripard), OMAP (Tony
>   Lindgren), Renesas (Simon Horman), Broadcom (Florian
>   Fainelli), Qualcomm (Andy Gross) and Freescale (Shawn Guo).
> 

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Michael Ellerman]

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

> On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote:
>> I'd like the maintainership summit list to be fairly small. Not even
>> 50 people. Maybe 30. A group that can actually sit in a room for half
>> a day and talk to each other about the issues they have rather than
>> being talked to. And talk literally about *process* issues, not about
>> any particular technical issues within whatever subsystem. Bring up
>> peeves or wishes for actual process improvements?
>> 
>> Comments? People who should be involved? Or people who don't have any
>> particular issues and want to not be involved?
>
> I'd like closure on one process issue, if we could achieve it:
>
> Maintainer script automation: Quite a few of us have maintainer scripts
> that send automated email notifications of the status of patches in the
> tree (mostly to stop people flooding the lists with questions about
> what happened to their patches).  We did a script show and tell at the
> last kernel summit, but perhaps we could get closure on a couple of
> issues:
>
>    1. Since most people agree that these form of notifications are useful,
>       should we have a standard email for it (or at least a list of things
>       which should be in that email, like commit-id, tree, maintainer,
>       mailing list and the version of the kernel it is expected to be
>       pushed for).

We could have suggestions, I'm not sure an actual standard is feasible
given the differences in the processes people use.

>    2. Given that we all run ad-hoc infrastructure to produce these emails,
>       could we get a set of blessed scripts up on kernel.org for all
>       comers so we can use the central infrastructure rather than rolling
>       our own.

This would be great.

But is there actually a set of scripts out there which are in
sufficiently good state that we could ask the kernel.org admins to run
them?

If the mail sending happens on kernel.org how do the scripts know which
mail to respond to for a given commit? It could be in the commit message
somehow, but that's ugly. My scripts use git-notes for that sort of
metadata, which works quite well, so maybe that's an option.

Or maybe you're thinking that they don't reply to the original patch,
they just mail the author?

There's also times when you push commits that have already been
responded to by someone else (ie. a submaintainer), so there'd need to
be some way to flag that. And then obviously the case where you fast
forward to Linus' branch, you don't want to send mails for all those
commits :)

Another thing that's nice is to only send one mail when you merge a big
series, which complicates things a bit more.

Anyway a slightly old version of my terrible scripts are here, if anyone
wants to have a look.

  https://github.com/mpe/patchwork-scripts

They rely on having the mbox of the original patch in .git/patchwork, and
they don't actually send the mails, just generate them, allowing some
manual tweaking before sending.

cheers

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mauro Carvalho Chehab]

Em Fri, 21 Apr 2017 10:59:55 +0200
Wolfram Sang <wsa@the-dreams.de> escreveu:

> > I think patchwork notifications are sent only to people with a patchwork
> > account so this is not enough for subsystems with a lot of drive-by
> > contributors.  
> 
> It can be configured to send emails to everyone. But you need to ask the
> admin to do that. Jeremy did that for me on ozlabs with the i2c-list.

Such setting is enabled for linux-media ML patch posts, at linuxtv.org
patchwork server. With that, if one doesn't want e-mails, he/she can create
an account at patchwork and opt-out.

Thanks,
Mauro

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[David Miller]

From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date: Fri, 21 Apr 2017 10:41:55 +0200

> On 20/04/2017 at 11:31:31 +0300, Jani Nikula wrote:
>> On Wed, 19 Apr 2017, Laura Abbott <labbott@redhat.com> wrote:
>> > I brought up bug reporting last year and I still consider that to be
>> > an issue this year. A good example is
>> > https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really
>> > make progress until I sent out a separate e-mail thread summarizing
>> > the bisections people did.
>> 
>> The service level at https://bugzilla.kernel.org heavily depends on the
>> subsystem/driver. Some maintainers just ignore it completely.
>> MAINTAINERS now has the "B:" entry to document where maintainers want
>> bugs reported, and I'd like to see more maintainers document their
>> preferences there.
>> 
> 
> I think that addition has not been noticed by many maintainers and that
> is actually one of my pain point.

Indeed, I was completely unaware of this.  Now that I am I have added
an appropriate entry for the networking.

Thanks.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mauro Carvalho Chehab]

Em Fri, 21 Apr 2017 20:34:10 +1000
Michael Ellerman <mpe@ellerman.id.au> escreveu:

> Mauro Carvalho Chehab <mchehab@s-opensource.com> writes:
> 
> > Em Wed, 19 Apr 2017 13:20:37 -0700
> > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> >  
> >>    1. Since most people agree that these form of notifications are useful,
> >>       should we have a standard email for it (or at least a list of things
> >>       which should be in that email, like commit-id, tree, maintainer,
> >>       mailing list and the version of the kernel it is expected to be
> >>       pushed for).
> >>    2. Given that we all run ad-hoc infrastructure to produce these emails,
> >>       could we get a set of blessed scripts up on kernel.org for all
> >>       comers so we can use the central infrastructure rather than rolling
> >>       our own.  
> >
> > I suspect that this very much depends on the way each maintainer handle
> > patches. For subsystems like media, where we use patchwork, notification
> > comes for free with the tool.  
> 
> AFAIK patchwork can only notify the submitter of the patch, which is OK,
> but I think it's preferable if the notification goes to the recipient
> list of the original mail.
> 
> For example it's quite handy to know when another maintainer has merged
> a patch, so you don't merge it too, or wonder if you should.

If another maintainer picks a patch and merge, it will update the
patch status. So, refreshing the patch list will update it for you
too.

Ok, there still the risk of race issues, but, even with email
notifications you still have this risk, as you'll get the e-mail
only when the other maintainer "publishes" the patches he took
on git.

Btw, I forgot to say that[1], besides patchwork, we also use a
post-receive mailbomb script I wrote several years ago for the patches
that are actually applied at the main devel git tree (code enclosed).

[1] I don't use myself their notifications. I just store on some
random input box, in case someone complains about issues on it. 
Due to the way we work, I'm the only one that commits at the media
development tree. So, I completely forgot about that on my past
emails.

Thanks,
Mauro

The following script expects something like this at the git config
file:

[mailnotify]
	project = "subsystem_tree"
	from = my-commits-bounces@example.org
	to = my-commits@examples.org
	replyto = subsystem-ml@vger.kernel.org
	maxsize = 100000
	maxmsgs = 100
	comitteremail = my@email
#	url = http://example.org/cgit.cgi/my_tree.git
#	topic = master
	debug = 0


#!/usr/bin/perl
#
# Copyright (c) 2012-2016: Mauro Carvalho Chehab <mchehab@s-opensource.com>
# License: GPLv2
#
use warnings;
use strict;
use Getopt::Long;
use Date::Parse;
use Date::Format;
use Sys::Hostname;

$ENV{PATH} = '/usr/local/bin:/usr/bin:/bin';

my $program = $0;

my @refs;
my %parents;
#
# Retrieve all info from git config
#
my $project_name = qx(git config mailnotify.project) || "untitled";
my $smtp_server  = qx(git config mailnotify.smtpserver) || "localhost";
my $from         = qx(git config mailnotify.from) || sprintf('%s@%s', $project_name, hostname());
my $to           = qx(git config mailnotify.to) || die("No mail To:");
my $cfgcc        = qx(git config mailnotify.cc) || "";
my $replyto      = qx(git config mailnotify.replyto) || "";
my $maxsize      = qx(git config mailnotify.maxsize) || "";
my $maxmsgs      = qx(git config mailnotify.maxmsgs) || 0;
my $url          = qx(git config mailnotify.url) || "";
my $comitteremail= qx(git config mailnotify.comitteremail) || "";
my $debug        = qx(git config mailnotify.debug) || 0;
my $debug_dir    = qx(git config mailnotify.debugdir) || "queue";
my $mail_cmd     = qx(git config mailnotify.mailcmd) || "/usr/sbin/sendmail";
my $topic	 = qx(git config mailnotify.topic) || "";

GetOptions(
	   "debug" => \$debug,
	  );

$project_name =~ s/\s+$//;
$smtp_server =~ s/\s+$//;
$from =~ s/\s+$//;
$to =~ s/\s+$//;
$cfgcc =~ s/\s+$//;
$replyto =~ s/\s+$//;
$maxsize =~ s/\s+$//;
$url =~ s/\s+$//;
$comitteremail =~ s/\s+$//;
$debug =~ s/\s+$//;
$debug_dir =~ s/\s+$//;
$mail_cmd =~ s/\s+$//;
$topic =~ s/\s+$//;

if ($debug && !stat($debug_dir)) {
	mkdir $debug_dir, 0755 or die "Can't create $debug_dir";
}

#
# Get old revision, new revision and branch/tag name
#
my ($oldrev, $newrev, $refname);
if (scalar(@ARGV)) {
	($oldrev, $newrev, $refname) = @ARGV[ 0 .. 2 ];
} else {
	my $args = <STDIN>;
	($oldrev, $newrev, $refname) = split(" ", $args);
}

if (!$refname) {
	$refname = qx(git describe --all $newrev|grep heads/);
	$refname =~ s,heads/,,;
}

if (!$oldrev || !$newrev || !$refname) {
	printf(STDERR "Arguments missing. Can't proceed\n");
	exit -1;
}

printf(STDERR "Running: $0 %s %s %s\n", $oldrev, $newrev, $refname);

# Avoid errors like
# remote: fatal: Invalid revision range 0000000000000000000000000000000000000000..4dbd68c7a6b13ef1313f51468f1b154d11e5f934
if ($oldrev eq "0000000000000000000000000000000000000000") {
	printf(STDERR "Warning: using 'master' branch as old rev\n");
	$oldrev = "master";
}

#
# Get the complete revision name
#
$oldrev = qx(git rev-parse $oldrev);
$newrev = qx(git rev-parse $newrev);

chomp($oldrev);
chomp($newrev);
chomp($refname);

if ($debug) {
    printf(STDERR "oldrev:%s\n", $oldrev);
    printf(STDERR "newrev:%s\n", $newrev);
    printf(STDERR "refname:%s\n", $refname);
}

#
# Get branch name
#
my $branch = (split("/", $refname))[-1];

if ($topic ne "") {
	my $parentbranch = "";

	$parentbranch = (split("/", $refname))[-2] if (scalar(split("/", $refname)) > 1);
	$parentbranch = $refname if (!$parentbranch);
	printf(STDERR "expected parent branch:%s\n", $topic) if ($debug);
	printf(STDERR "current parent branch:%s\n", $parentbranch) if ($debug);

	if ($parentbranch ne $topic) {
		printf(STDERR "Branch $parentbranch: topic $topic don't generate emails.\n");
		exit 0;
	}
}

#
# get all changesets from $oldrev to $newrev, with their parents
#
my $n_patches = 0;
my $n_ignored = 0;
open REF, "git rev-list $oldrev..$newrev|";
while (<REF>) {
	my $curref = $_;
	$curref =~ s/\s+$//;

	if ($comitteremail) {
		my $comitter = qx(git log --pretty=format:%ce $curref -1);
		print "$comitter is not maintainer\n" if ($debug && !($comitter =~ m/($comitteremail)/));
		if (!($comitter =~ m/($comitteremail)/)) {
			$n_ignored++;
			next;
		}
	}
	push @refs, $curref;
	$n_patches++;
}
close REF;

if ($maxmsgs && ($n_patches > $maxmsgs)) {
	if ($comitteremail) {
		my $msg = "Subject: Warning: hook wants to send $n_patches patches!\nFrom: $from\nTo: $comitteremail\n\n";
		$msg .= "If this is not an error, please call\n\t" .
			  $program . " $oldrev $newrev $refname\n" .
			  "At the git server\n";
		if (!$debug) {
			open(MAIL, "| $mail_cmd -t");
			print MAIL $msg;
			close MAIL;
		} else {
			my $fname = "$debug_dir/error_msg";
			open(MAIL, ">$fname") or die "Can't create $fname";
			print MAIL $msg;
			close MAIL;
			print "Created $fname\n";
		}
	}
	# Abort script, letting the receive proceed
	exit 0;
}
#
# Remove merge changesets
#

print "Generating $n_patches emails.\n" if ($debug);

#
# Generate one email per changeset
#
my $count = 1;
foreach my $ref (@refs) {
	my %copy;
	my $log = "";

	# Add mandatory CC
	$copy{$cfgcc} = "" if ($cfgcc);

	my $comitter = qx(git log --pretty=format:"%cn <%ce>" $ref -1);
	my $comitter_email = qx(git log --pretty=format:"%ce" $ref -1);
	my $comitter_date = qx(git log --pretty=format:"%cd" $ref -1);

	# Convert date into rfc2822 format
	$comitter_date = time2str("%a, %d %b %Y %H:%M:%S %z", 
				  str2time($comitter_date));


	open IN, "git log -1 --pretty=email --stat $ref|";

	# Discard initial From line
	my $dumb=<IN>;

	my $header;
	my $is_header=1;
	while (<IN>) {
		# Proper handle header continuation fields
		if ($is_header) {
			if ($_ eq "\n") {
				$is_header = 0;
			} elsif (m/^\s/) {
				$header =~ s/\n$//;
				$header .= $_;
				next;
			} elsif (m/From:\s*(.*)\n/) {
				$header .= "From: $comitter\n";
			} elsif (m/Subject:\s*(.*)\n/) {
				my $s = $1;
				$s =~ s/^\[PATCH\]\s*//;
				$header .= sprintf("Subject: [git:%s/%s] %s\n", $project_name, $branch, $s);
			} elsif (m/Date:\s*(.*)\n/) {
				$header .= sprintf("Date: %s\n", $comitter_date);
			} else {
				$header .= $_;
			}
			next;
		}

		$log .= $_;
		if (m/(signed-off-by|author|from|accepted-by|tested-by|thanks-to|reviewed-by|cc|acked-by):\s*(.*)\s*\n$/i) {
			my $sob=$2;
			my $name;
			my $email;
			if ($sob =~ m/\s*(.*)\s*<(.*)>/) {
				$name = $1;
				$email = $2;
				$name =~ s/^\s+//;
				$name =~ s/\s+$//;
				$name =~ s/^\"(.*)\"$/$1/;
				$name="" if ($name =~ m/\@/);
			} elsif ($sob =~ m/([^\s\<]+\@[^\s+\>]+)/) {
				$email = $1;
				$name = "";
			}
			# Don't copy committer/stable
			next if ($email eq $comitter_email);
			next if ($email =~ m/stable\@kernel.org/i);

			$copy{"$email"} = $name if (!exists($copy{"$email"}));
		}
	}
	close IN;

	my $cc = "";
	while (my ($key,$value) = each(%copy) ) {
		if ($value ne "") {
			$cc .= ", $value <$key>";
		} else {
			$cc .= ", $key";
		}
	}
	$cc =~ s/^, //;
	$cc =~ s/\s+/ /g;

	my $diff = qx(git show --pretty=format:"" $ref);

	$header .= "To: $to\n";
	$header .= "Cc: $cc\n" if ($cc);

	if ($replyto) {
		$header .= "Mail-followup-to: $replyto\n";
		$header .= "Forward-to: $replyto\n";
		$header .= "Reply-to: $replyto\n";
	}

	my $author = qx(git log -1 --pretty=format:"%an <%ae>" $ref);
	my $subject = qx(git log -1 --pretty=format:"%s" $ref);
	my $date = qx(git log -1 --pretty=format:"%ad" $ref);

	my $comment = "This is an automatic generated email to let you know that the following patch were queued";
	if ($url) {
		$comment .= " at the \n$url tree:\n\n";
	} else {
		$comment .= ":\n\n";
	}
	$comment .= "Subject: $subject\n"
		  . "Author:  $author\n"
		  . "Date:    $date\n";

	my $email = "$header\n$comment\n$log\n---\n\n";
	$email   .= "$url/commit/?id=$ref\n" if ($url);
	if ($maxsize && length($diff) > $maxsize) {
		$diff = "<diff discarded since it is too big>\n"
	}
	$email .= $diff;

	if (!$debug) {
		open(MAIL, "| $mail_cmd -t");
		print MAIL $email;
		close MAIL;
	} else {
		my $fname = "$debug_dir/patch-$count-$ref.patch";
		open(MAIL, ">$fname") or die "Can't create $fname";
		print MAIL $email;
		close MAIL;
		print "Created $fname\n";
	}

	$count++;
}
printf STDERR "Sent %d emails.\n", $count - 1;
printf STDERR "Ignored %d patches that were not committed by $comitteremail.\n", $n_ignored if ($n_ignored);

close REF;

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mauro Carvalho Chehab]

Em Fri, 21 Apr 2017 21:07:24 +1000
Michael Ellerman <mpe@ellerman.id.au> escreveu:

> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> 
> > On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote:  
> >> I'd like the maintainership summit list to be fairly small. Not even
> >> 50 people. Maybe 30. A group that can actually sit in a room for half
> >> a day and talk to each other about the issues they have rather than
> >> being talked to. And talk literally about *process* issues, not about
> >> any particular technical issues within whatever subsystem. Bring up
> >> peeves or wishes for actual process improvements?
> >> 
> >> Comments? People who should be involved? Or people who don't have any
> >> particular issues and want to not be involved?  
> >
> > I'd like closure on one process issue, if we could achieve it:
> >
> > Maintainer script automation: Quite a few of us have maintainer scripts
> > that send automated email notifications of the status of patches in the
> > tree (mostly to stop people flooding the lists with questions about
> > what happened to their patches).  We did a script show and tell at the
> > last kernel summit, but perhaps we could get closure on a couple of
> > issues:
> >
> >    1. Since most people agree that these form of notifications are useful,
> >       should we have a standard email for it (or at least a list of things
> >       which should be in that email, like commit-id, tree, maintainer,
> >       mailing list and the version of the kernel it is expected to be
> >       pushed for).  
> 
> We could have suggestions, I'm not sure an actual standard is feasible
> given the differences in the processes people use.
> 
> >    2. Given that we all run ad-hoc infrastructure to produce these emails,
> >       could we get a set of blessed scripts up on kernel.org for all
> >       comers so we can use the central infrastructure rather than rolling
> >       our own.  
> 
> This would be great.
> 
> But is there actually a set of scripts out there which are in
> sufficiently good state that we could ask the kernel.org admins to run
> them?
> 
> If the mail sending happens on kernel.org how do the scripts know which
> mail to respond to for a given commit? It could be in the commit message
> somehow, but that's ugly. My scripts use git-notes for that sort of
> metadata, which works quite well, so maybe that's an option.
> 
> Or maybe you're thinking that they don't reply to the original patch,
> they just mail the author?
> 
> There's also times when you push commits that have already been
> responded to by someone else (ie. a submaintainer), so there'd need to
> be some way to flag that. And then obviously the case where you fast
> forward to Linus' branch, you don't want to send mails for all those
> commits :)

The script I posted on my past e-mail handles it using two algorithms:

	- It checks for the committer e-mail. If the patch isn't
	  committed by me, it skips the patch;

	- It prevents sending more than a certain number of e-mails,
	  with is configurable at git config file. That prevents
	  mailbomb patches that I committed via some other tree
	  (like edac).

With those two rules, automatic mailbomb actually looks OK.

> Another thing that's nice is to only send one mail when you merge a big
> series, which complicates things a bit more.

That would be interesting, but prevents pushing the actual patch.
In our case, we mailbomb patches also to a mailing list, allowing
others to review and comment on patches actually applied.

Thanks,
Mauro

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Bjorn Helgaas]

On Wed, Apr 19, 2017 at 3:20 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> I'd like closure on one process issue, if we could achieve it:
>
> Maintainer script automation: Quite a few of us have maintainer scripts
> that send automated email notifications of the status of patches in the
> tree (mostly to stop people flooding the lists with questions about
> what happened to their patches).  We did a script show and tell at the
> last kernel summit, but perhaps we could get closure on a couple of
> issues:

I wasn't at the last summit, and there's a lot of room for improvement
in this area of my life.  Is this show and tell available anywhere?

>    1. Since most people agree that these form of notifications are useful,
>       should we have a standard email for it (or at least a list of things
>       which should be in that email, like commit-id, tree, maintainer,
>       mailing list and the version of the kernel it is expected to be
>       pushed for).
>    2. Given that we all run ad-hoc infrastructure to produce these emails,
>       could we get a set of blessed scripts up on kernel.org for all
>       comers so we can use the central infrastructure rather than rolling
>       our own.
>
> The other things I think it might do us all good is to have a frank
> session on "tasteful rebasing".  We've come around (finally) to the
> conclusion that rebasing isn't always bad.  My own opinion is that
> rebasing to fix issues in patches (particularly those marked for
> stable) so they can backport cleanly and atomically.  There's also less
> of a consensus that rebasing to clean up history is a reasonably good
> thing (provided it's not done just before requesting a pull).  However,
> we have a divergence of opinions not just on whether we should rebase,
> but what constitutes a tasteful rebase.  Just telling people,
> particularly would be new maintainers, that it's a judgement call
> always is unhelpful, we could do with putting together some more
> detailed guidance (assuming we can agree on it).

I'm interested in this, too.  I update topic branches regularly to add
acks, fix typos, fold in fixes discovered before merging to Linus,
etc.  I assume that as long as it hasn't been merged, doing that as
separate patches would just be clutter.  But maybe I'm making life
difficult for contributors who consume those branches.  I almost
always apply patches from email (as opposed to pulling via git), and I
typically base the topic branches on -rc1 or -rc2, because that makes
it simple for me to do these updates.

Bjorn

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Fri, 2017-04-21 at 12:06 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 21 Apr 2017 20:34:10 +1000
> Michael Ellerman <mpe@ellerman.id.au> escreveu:
> 
> > Mauro Carvalho Chehab <mchehab@s-opensource.com> writes:
> > 
> > > Em Wed, 19 Apr 2017 13:20:37 -0700
> > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > >  
> > > >    1. Since most people agree that these form of notifications 
> > > > are useful,       should we have a standard email for it (or at 
> > > > least a list of things which should be in that email, like 
> > > > commit-id, tree, maintainer, mailing list and the version of 
> > > > the kernel it is expected to be pushed for).
> > > >    2. Given that we all run ad-hoc infrastructure to produce 
> > > > these emails, could we get a set of blessed scripts up on 
> > > > kernel.org for all comers so we can use the central 
> > > > infrastructure rather than rolling our own.  
> > > 
> > > I suspect that this very much depends on the way each maintainer 
> > > handle patches. For subsystems like media, where we use 
> > > patchwork, notification comes for free with the tool.  
> > 
> > AFAIK patchwork can only notify the submitter of the patch, which 
> > is OK, but I think it's preferable if the notification goes to the
> > recipient list of the original mail.
> > 
> > For example it's quite handy to know when another maintainer has 
> > merged a patch, so you don't merge it too, or wonder if you should.
> 
> If another maintainer picks a patch and merge, it will update the
> patch status. So, refreshing the patch list will update it for you
> too.
> 
> Ok, there still the risk of race issues, but, even with email
> notifications you still have this risk, as you'll get the e-mail
> only when the other maintainer "publishes" the patches he took
> on git.
> 
> Btw, I forgot to say that[1], besides patchwork, we also use a
> post-receive mailbomb script I wrote several years ago for the 
> patches that are actually applied at the main devel git tree (code
> enclosed).

Yes, mine is a special git tree on hansenpartnership.com that does the
same thing.  I'd rather like not to run git on my cloud system, hence
the rather selfish question about whether we could do it on kernel.org.

> [1] I don't use myself their notifications. I just store on some
> random input box, in case someone complains about issues on it. 
> Due to the way we work, I'm the only one that commits at the media
> development tree. So, I completely forgot about that on my past
> emails.
> 
> Thanks,
> Mauro
> 
> The following script expects something like this at the git config
> file:

Looking at yours, it doesn't seem to handle either rebasing or patch
removing.  Attached is mine, which does both.  A patch update gets both
a remove and an add patch.  I do the same correct committer check (did
have a cockup several years ago where I updated the wrong branch and
sent out several hundred emails before I managed to kill it).

Mine's also complicated by the fact I used to run a pending tree where
I put patches that I thought needed reviewing but the maintainer hadn't
yet reviewed them.  The script would also send out periodic nag mails
about reviews.

it's designed to operate on my trees, which carry both a <branch> and a
<branch>-base branch which is used to work out what patches actually
belong to me.  I should really switch over to using git-mergebase for
this, but haven't got around to it yet.

James

---

#!/usr/bin/perl
#
# An example hook script to mail out commit update information.
# It can also blocks tags that aren't annotated.
# Called by git-receive-pack with arguments: refname sha1-old sha1-new
#
# To enable this hook, make this file executable by "chmod +x update".
#
# Config
# ------
# hooks.mailinglist
#   This is the list that all pushes will go to; leave it blank to not send
#   emails frequently.  The log email will list every log entry in full between
#   the old ref value and the new ref value.
# hooks.announcelist
#   This is the list that all pushes of annotated tags will go to.  Leave it
#   blank to just use the mailinglist field.  The announce emails list the
#   short log summary of the changes since the last annotated tag
# hooks.allowunannotated
#   This boolean sets whether unannotated tags will be allowed into the
#   repository.  By default they won't be.
#
# Notes
# -----
# All emails have their subjects prefixed with "[SCM]" to aid filtering.
# All emails include the headers "X-Git-Refname", "X-Git-Oldrev",
# "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and info.

# --- Constants
chomp($cwd=`pwd`);
require $cwd.'/hooks/update-variables.pl' || die;

# branches which comprise the base of the tree (i.e. ones not to
# report commits in) for a push of master.  The default is 'linus'.
# 'merge-base' only gets used when the tree has to be based on a
# non-standard tree because of conflicts
%BRANCHES = (
    'merge-base' => 1,
    'linus' => 1,
);
%IGNORED_BRANCHES = (
    'for-next' => 1,
    'for-linus' => 1,
    'master' => 1,
);
@IGNOREDCC = (
    'stable@kernel.org',
    'stable@vger.kernel.org',
);

%EMAILTO = (
    'James.Bottomley@HansenPartnership.com' => 1,
    'martin.petersen@oracle.com' => 1,
);

# --- Command line
$refname = $ARGV[0];
if ($refname =~ m|^refs/tags/|) {
    $refname =~ s|^refs/tags/||;
    $tag = 1;
} else {
    $refname =~ s|^refs/heads/||;
}
$oldrev=$ARGV[1];
$newrev=$ARGV[2];

# --- Safety check
if ($ENV{'GIT_DIR'} eq '') {
	print STDERR "Don't run this script from the command line.";
	print STDERR " (if you want, you could supply GIT_DIR then run";
	print STDERR "  $0 <ref> <oldrev> <newrev>)";
	exit 1;
}

if ($refname eq '' || $oldrev eq '' || $newrev eq '') {
	print STDERR "Usage: $0 <ref> <oldrev> <newrev>";
	exit 1;
}

if ($tag) {
    chomp(@t = `git cat-file tag $newrev`);
    foreach (@t) {
	if (/^tagger (.*>)/) {
	    $recipients = $1;
	    break;
	}
    }

    if (!$recipients) {
	print STDERR "Can't find a tagger in $refname\n";
	exit 1;
    }

    if (%EMAILTO) {
	$EMAILTO{$recipients} = 1;

	$recipients = join(', ', keys(%EMAILTO));
    }

    chomp(@_ = `git merge-base $newrev master`);

    $oldrev = $_[0];

    chomp(@commitlist = `git rev-list $newrev ^$oldrev`);

    @commitlog = ();
    foreach $commit (@commitlist) {
	chomp(@_ = `git show --oneline $commit`);
	push @commitlog, $_[0];
    }
    @email = (
# Generate header
	"From: James Bottomley <James.Bottomley\@HansenPartnership.com>",
	"To: $recipients",
	"Subject: Tag $revname added to tree ${TREE}",
	"X-Git-Oldrev: $oldrev",
	"X-Git-Newrev: $newrev",
	"X-Git-Tree: $TREEHDR",
	"",
	"Your tag $refname",
	"",
	"Containing:",
	);
    push @email, @commitlog;
    push @email, (
	"",
	"has been added to the $TREETYPE $TREE tree",
	"",
	"You can find it here:",
	"",
	"http://git.kernel.org/?p=linux/kernel/git/jejb/${TREE}.git;a=tag;h=$newrev",
	"",
	$WHENPUSH,
	"",
	"James Bottomley",
	"",
	"P.S. If you find this email unwanted, set up a procmail rule junking on",
	"the header:",
	"",
	"X-Git-Tree: $TREEHDR",
	"",
    );
    open(EMAIL, "| /usr/sbin/sendmail -t") || die;
    print EMAIL join("\n", @email);
    close(EMAIL);
    #print STDERR join("\n", @email);
    print STDERR "Email sent to: $recipients\n";
    exit 0;
}

if ($IGNORED_BRANCHES{$refname}) {
    print STDERR "Branch $refname ignored, not generating email\n";
    exit 0;
}
if ($refname =~ m/-base$/ || $BRANCHES{$refname}) {
    print STDERR "Updating base branch\n";
    exit 0;
}

$branch = '';
chomp(@branches = `git branch`);

if ($refname eq 'master') {
    foreach $b (keys(%BRANCHES)) {
	next if (!grep(/^..$b/,@branches));
	$branch = $b;
	last;
    }
} elsif (grep(/^..${refname}-base/,@branches)) {
    $branch = $refname.'-base';
}

if (!$branch) {
    print STDERR 'Upstream head has no needed bases: '.join(" ", @BRANCHES)." or ${refname}-base\n";
    exit 1;
}

if ($oldrev eq '0000000000000000000000000000000000000000' ) {
    print STDERR "Creating new branch $refname\n";
    exit 0;
}

@commitlist = ();
chomp(@revlist = `git rev-list --no-merges $newrev ^$oldrev ^$branch`);
chomp(@cherrylist = `git cherry $refname $newrev`);

# don't annoy Linus guard: check that all of the cherrylist is actually mine
foreach $commit (@revlist) {
    # - prefix means the commit from $newrev is already in $branch
    next if (grep(/^- $commit/, @cherrylist));
    push @commitlist, $commit;
    $_ = `git log --pretty='format:%cn' $commit^..$commit`;
    next if (/^James Bottomley/);
    next if (/^Christoph Hellwig/);
    next if (/^Martin K. Petersen/);
    print STDERR "ERROR: commit $commit is not yours\n";
    print STDERR "ERROR: $_\n";
    exit 1;
}

$WHENPUSH = $WHENPUSHED{$refname};
if (!$WHENPUSH) {
    $WHENPUSH = $WHENPUSHED{'default'};
}
$NEEDACKS = $NEEDACKS{$refname};

#find the deleted commits and add them to the commit list
chomp(@deletelist = `git cherry $newrev $refname $branch`);
foreach $_ (@deletelist) {
    next if (!m/^\+ /);
    # found a delete; add it to the email list keeping the + prefix
    push @commitlist, $_;
}

foreach $commit (@commitlist) {
    if ($commit =~ m/^\+ /) {
	$commit = substr($commit,2);
	$delete = 1;
	$EMAILPREFIX="Patch dropped from ${TREE}: ";
    } else {
	$delete = 0;
	$EMAILPREFIX="Patch added to ${TREE}: ";
    }
    
    @email = ();
    $author = '';
    if (%EMAILTO) {
	%recipients = %EMAILTO;
    }
    %ackrequired = ();
    $subject = '';

    outer: foreach $_ (`git log $commit^..$commit`) {
	if (/^    / && $subject eq '') {
	    chomp($subject = substr($_, 4));
	} elsif (/^Author: / && $author eq '') {
	    chomp($author = substr($_, 8));
	    $recipients{$author} = 1;
	} elsif (/^    signed-off-by: /i) {
	    chomp($a = substr($_, 19));
	    $recipients{$a} = 1;
	    delete $ackrequired{$a};
	} elsif (/^    reviewed-by: /i) {
	    chomp($a = substr($_, 16));
	    $recipients{$a} = 1;
	    delete $ackrequired{$a};
	} elsif(/^    acked-by: /i) {
	    chomp($a = substr($_, 14));
	    $recipients{$a} = 1;
	    delete $ackrequired{$a};
	} elsif(/^    tested-by: /i) {
	    chomp($a = substr($_, 15));
	    $recipients{$a} = 1;
	    delete $ackrequired{$a};
	} elsif(/^    reported-by: /i) {
	    chomp($a = substr($_, 17));
	    $recipients{$a} = 1;
	    delete $ackrequired{$a};
	} elsif (/^    cc: /i) {
	    chomp($a = substr($_, 8));
	    foreach(@IGNOREDCC) {
		if ($a =~ m/$_/) {
		    next outer;
		}
	    }
	    $recipients{$a} = 1;
	    $ackrequired{$a} = 1;
	}
    }
    # I don't want to receive email
    #delete $recipients{'James Bottomley <James.Bottomley@SteelEye.com>'};
    # --- Email (all stdout will be the email)
    $recipients = join(', ', keys(%recipients));
    #$recipients = 'James.Bottomley@HansenPartnership.com';
    
    @email = (
# Generate header
	      "From: James Bottomley <James.Bottomley\@HansenPartnership.com>",
	      "To: $recipients",
	      "Subject: ${EMAILPREFIX} $subject",
	      "X-Git-Oldrev: $oldrev",
	      "X-Git-Newrev: $newrev",
	      "X-Git-Tree: $TREEHDR",
	      "",
# body goes here
	      "Your commit:",
	      );
    chomp(@commitlog = `git log $commit^..$commit`);
    # get rid of the commit/author/date header
    shift @commitlog;
    shift @commitlog;
    shift @commitlog;
    push @email, @commitlog;
    if ($delete) {
	push @email, (
	    "",
	    "has been dropped from the $TREETYPE $TREE tree",
	    "On branch \"$refname\"",
	    "",
	);
    } else {
	push @email, (
	      "",
	      "has been added to the $TREETYPE $TREE tree",
	      "On branch \"$refname\"",
	      "You can find it here:",
	      "",
	      "http://git.kernel.org/?p=linux/kernel/git/jejb/${TREE}.git;a=commit;h=$commit",
	      "",
	      $WHENPUSH,
	);
    }
    if ($NEEDACKS && %ackrequired) {
	push @email, (
	       "",
	       "This patch is pending because it requires ACKs from:",
	       "",
	       join("\n", keys(%ackrequired)),
	       "",
	       "If those are received it may be moved into one of the upstream SCSI trees",
		      );
    }
    push @email, (
	      "",
	      "James Bottomley",
	      "",
	      "P.S. If you find this email unwanted, set up a procmail rule junking on",
	      "the header:",
	      "",
	      "X-Git-Tree: $TREEHDR",
	      "",
	      );
    open(EMAIL, "| /usr/sbin/sendmail -t") || die;
    print EMAIL join("\n", @email);
    close(EMAIL);
    #print STDERR join("\n", @email);
    print STDERR "Email sent to: $recipients\n";
}

exit 0

---

The update-variables.pl looks like this:

$_=`git tag -l 'v*'`;
chomp;
my ($major, $minor) = (0,0);
foreach $_ (split /\n/) {
    my ($lmajor, $lminor) = m/v(\d+)\.(\d+)-rc\d$/;
    ($major, $minor) = ($lmajor, $lminor) if ($lmajor > $major || ($lmajor == $major && $lminor > $minor));
}
$_=`git tag -l 'v${major}.${minor}'`;
# $_ is populated if we're in a merge window
$minor++ if ($_);
my $cur = $major.'.'.$minor;
my $next = $major.'.'.($minor + 1);
$TREE = "scsi";
$TREETYPE = "upstream";
$TREEHDR = 'SCSI';
%WHENPUSHED = (
	"default" => "This patch is scheduled to be pushed when the merge window opens for $next",
	"fixes" => "This patch is scheduled to be pushed for $cur",
	"pending" => "This patch is not on an upstream branch",
	"postmerge" => "This patch is scheduled to be pushed when the merge window opens for $next but depends on another tree which must be pushed first",
);
%NEEDACKS = (
	"pending" => 1
);

1;

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Nicolas Ferre]

Le 21/04/2017, 13:03, Alexandre Belloni wrote:
> Hi,
> 
> On 19/04/2017 at 22:26:34 +0200, Arnd Bergmann wrote:
>> On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>
>>> What I _would_ like to see is those top maintainers suggest
>>> "submaintainer" names. Particularly Davem, since he doesn't tend to
>>> want to come to the kernel summit, and being at the top of the list
>>> that's a kind of big gaping hole. I guess we haven't had all that many
>>> _problems_ within networking, but if we talk maintainership issues,
>>> it's certainly a bit odd if it's entirely lacking. We have both core
>>> networking and network drivers that both fall under "davem" as far as
>>> my pull statistics go.
>>
>> For ARM, the work also tends to be fairly spread out across many
>> people, with few of us being overly important. [I think that while Olof and
>> I had similar shares of work in pulling in patches, I ended up in one of
>> the top spots because I happened to send more pull requests during
>> the last year, and I also did quite a bit of kernel stuff outside of
>> arch/arm.]
>>
>> So while there is no need for having lots of ARM platform maintainers,
>> I would like to see some of the people that I interact with that also
>> work with a larger number of other maintainers:
>>
>> - One of the device tree maintainers (Rob Herring, Frank Rowand,
>>   Mark Rutland), they inevitably deal with almost all device driver
>>   writers at some point
>>
>> - One of the CLK subsystem maintainers (Michael Turquette,
>>   Stephen Boyd), they also interact with a large number of
>>   subsystem and platform maintainers, and we have had some
>>   disagreements particularly when dealing with three subsystems
>>   (clk, arm-soc and a device driver) in one patch series.
>>
>> - One or two ARM platform maintainers, ideally one that also
>>   maintains another kernel subsystem.
> 
> I would fit that description, although mach-at91 is so small now that we
> have very few issues with arm-soc. However, I have two particular
> points:
>  - what to do which the many coccinelle generated patches that are sent.
> I find that many are not tested, don't really improve readability and
> are sometimes harmful. I used to apply them, I don't anymore because
> they sometimes take too much time to review for absolutely zero benefit.
> The main category is the switch to devm_ functions in old drivers that
> are already handling error case pretty well.
>  - my subsystem (RTC) is pretty dependant on two bus subsystems (I2C and
>    SPI). Sometimes, it would be good to be included in discussions that
> will affect many drivers instead of finding that they have to be patched
> after the fact. I'm mainly thinking about recent work from Javier
> regarding OF matching in i2c. The main drawback of including more people
> is probably the bikeshedding that will ensue but I feel like more
> coordination would have been necessary to make Javier's life a bit
> easier.

Alexandre, correct me if I'm wrong but you could also comment on the
ways to work with several co-maintainers. You have a long experience
with this way of handling an ARM platform (at91, mostly with me ;-)).

Co-maintainship was established 6 years ago in at91 and I think that it
can be good to discuss about the best ways to put in place this model
and the best practice to make it successful. Because we usually hear
about it as the panacea but I do think it also has some severe drawbacks
or limitations.
Don't get me wrong, I do like the work we are doing right now with at91 ;-).

Best regards,
-- 
Nicolas Ferre

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Olof Johansson]

On Thu, Apr 20, 2017 at 6:46 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Thu, Apr 20, 2017 at 1:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thu, Apr 20, 2017 at 10:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>> On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> I think discussing arm-soc vs. driver subsystem flows would be good.
>>> Not a personal gripe of mine, but since I seem to be volunteered to
>>> rep drm overall a topic I have to bring in. We have plenty of cross
>>> maintainer patch series and depencies in drm, and the usual way we
>>> handle this is:
>>> - get it reviewed by everyone
>>> - then either get acks from the subsystems (when it's smaller patches,
>>> or well separated from other stuff going on in that subsystem) to
>>> merge it all through one tree (usually the one with the most patches
>>> in the series)
>>> - or create a topic branch and send around cross-subsystem pull requests.
>>>
>>> This works rather well, and we have a bunch of cross-subsystem
>>> depencies we handle each month this way with trees outside of drm, not
>>> including the coordination needs within drm among different drm trees.
>>>
>>> In arm-soc this seems to not happen, and instead your nice bisectable
>>> patch series which implements an overall feature is split up into a
>>> bunch of trees, which then get forwarded independently. That means the
>>> bisect benefits are out, testing gets harder (either you have your own
>>> integration tree, or try to test linux-next and suffer), and sometimes
>>> even the final patches to enable something or switch drivers for a
>>> platform need to be delayed by an entire release.
>>
>> Do you know of a specific example where this happened? We try
>> to take a lot of care to ensure that each of the branches is bisectable,
>> so it sounds like we (or our downstream developers) were missing
>> something in the QA testing if this failed repeatedly.
>>
>> When I'm aware of a change that requires cross-tree coordination
>> (e.g. a Kconfig symbol gets renamed, or a DT binding changes
>> in an incompatible way), we usually try to come up with a way to
>> do the change differently (e.g. add have multiple Kconfig symbols
>> with the same meaning for a release or two, or find a way to
>> make the binding backwards compatible after all), but we also
>> frequently give Acks for merging stuff in arch/arm, or have a shared
>> tree that gets merged through both a driver subsystem and one
>> of our branches.
>
> Not "broken bisecting" as in if you bisect you might hit a broken
> configuration, but reduced usefulness for figuring out bugs. If a
> bigger feature or change in driver that also comes with some
> clk/irqchip/whatever changes, or an entire rewrite, then I've heard of
> examples where the splitting across trees meant that your bisect would
> end up in one of the merge commits (whichever is the last one that
> adds the missing piece) instead of somewhere in the middle like if the
> original patch series would have landed as linear history in a topic
> branch.
>
> Might just be good to chat a bit about when exactly a topic branch is
> called for, and when exactly merging through each separate tree is
> better. I get a bit the feeling that merging through separate trees is
> done to make sure platforms use all the infrastructure correctly
> (which is the topic below), but it seems like DT managed to get there
> without merging things stricly only through a DT tree.

You're likely to see this even with topic branches, for example you
won't see issues with a new driver until said driver is turned on in
the config. I do agree that it's frustrating to debug issues that only
show up once two branches are merged though.

For DT, the main effort has been in trying to make sure that bindings
get reviewed before they go in, but there hasn't been much
stepping-on-toes between the bindings.

The main reason we want ARM DT updates merged through our tree, is
that we've seen some horrible messes caused when there hasn't been
coordination between driver and platform developers/maintainers, and
we've seen some horrible conflict messes in the past. Also, since DT
is supposed to be about describing the hardware of the system, it's so
far seemed appropriate to have the platform maintainer merge it and do
so through our tree.

Still, every few releases we see conflicts reported by Stephen where
some driver maintainer has picked up DT contents and it conflicts
across trees. Often it happens with new platform maintainers not
knowing to avoid sending these out, and driver maintainers happily
applying them. We usually just bring it up quietly with the people
affected, since most conflicts are simple add/add context cases. It
would be nice to get a bit more awareness of our preferences out to
other maintainers as well.

It might have been 5+ years by now, but we also still have some scars
from where ARM platforms had some serious issues due to lack of
coordination, so we're still conservative in this area. DT is
high-volume contents that's really convenient to have in-tree, but if
we start seeing frequent conflicts pressure will build up to get it
out of the kernel repo.

I'd be happy to meet and discuss this, and I'd be happy to get more
feedback from you on what you're ideally looking for in person or over
email. My name hasn't showed up much on the short lists for reasons
Arnd mentioned, but I'm likely to be around for hallway track to
discuss.

>>> Related to this is that there's no single stop-shop for driver
>>> submissions for the arm platform stuff, but it's all split up. Fairly
>>> often that means at least one of the maintainers doesn't like your
>>> face, is on vacation or leave, burried for other reasons, or at least
>>> has slightly different ideas about what color the bikeshed needs to
>>> be. That makes contributions for people who just want to get their
>>> driver for a given platform in a pain.
>>
>> This is in a large part by design: we used to have a problem with
>> dozens of platforms in arch/arm/mach-* doing the same things
>> slightly differently, each of them being controlled only by a single
>> platform maintainer. We have over time introduced many separate
>> subsystems (irqchip, rtc, gpio, pinctrl, iommu, clk, timer, led, pci,
>> cpufreq, cpuidle, pwm, dmaengine, phy, regulator, memory,
>> nvmem, thermal, hwspinlock, mailbox, reset, and probably a few
>> others), and moved code out of our responsibility into those
>> subsystems that are maintained independently.
>>
>> The subsystem maintainers have a much better understanding
>> of how things work in their domain across all the platforms, so
>> we get better review than we had in the 2.6 days when this all
>> fell upon a single architecture or platform maintainer. You still
>> typically have to get new changes approved by both a platform
>> maintainer (for your SoC) as well as the subsystem maintainer,
>> and I consider that a good idea. The price for it however is that
>>  anyone working on a single platform has to deal with a
>> multitude of git trees, and things become harder at the point
>>  where they interact, especially when you migrate a platform
>> from old-style board files to devicetree.
>>
>> Fortunately these days, the vast majority of changes we deal
>> with are purely additions of new drivers or features, so there
>> are rarely any actual cross-tree dependencies or conflicts any
>> more: The only things that we merge through arm-soc most
>> of the time are defconfig additions, dts file changes and
>> sometimes new Kconfig symbols for new platforms, and all
>> of them can come in any order without causing regressions.
>
> Just to clarify: I'm very impressed with all the infrastructure the
> arm-soc folks manged to pull off, and I understand why you have them
> all and how it works. But having bigger groups for bus factor reasons
> and making it easier for totally new contributions to not get
> completely lost and leave in frustration might be good.

Agreed. We're starting to see a few new platforms again, and getting
more info on how to do these things might be useful.

Maybe it's time for another ARM-SoC talk at a conference to refer to,
the last ones weren't really aimed at new contributors, and are
somewhat outdated.

> DRM is also
> fairly big nowadays, with piles of helpers and libraries for different
> things (not quite at the level of arm-soc yet), but we try to give new
> driver submissions one person who handles the entire thing, and pulls
> in acks from specific experts as needed. Still needs some working out
> and maybe formalizing the process more (atm it's mostly coordination
> over irc), but with group maintiners for all areas and load balancing
> between them that seems to work fairly well. While still making sure
> that new drivers use all the latest helpers and best practices (we add
> them constantly, so almost always something that could be simplified
> by using a new thing just merge 1-2 months ago). And sharing knowledge
> about all these things amongst maintainers and reviewers.

DRM is a really active subsystem, and it definitely has some
challenges due to it (like all highly active areas of development). I
think it's one of the driver subsystems that touch core kernel code
the most, something that's easily noticed when trying to port DRM to
older/newer kernels. It seems to me that you can really tell when a
subsystem is maintained by people who have to worry about
back/forward-ports and when someone mostly worries about making it
work as well as possible on the current kernel, and change whatever's
needed to make that happen. Neither is better than the other in my
opinion, but they obviously have different tradeoffs.

> And yeah, rewriting an entire platform from the old to the new model
> is a different beast on its own, this here is just from the pov of
> submitting individual drivers.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Walleij]

On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> Might just be good to chat a bit about when exactly a topic branch is
> called for, and when exactly merging through each separate tree is
> better. I get a bit the feeling that merging through separate trees is
> done to make sure platforms use all the infrastructure correctly
> (which is the topic below), but it seems like DT managed to get there
> without merging things stricly only through a DT tree.

What has been mentioned about Kconfig symbols being merged in
one place and then turned on in a merge commit is just part of it
really. To me the big pain is always API/file dependencies.

The typical case where we have to have a immutable topic branch
is when there is a new API (or just a header file really) added in one
patch and then a slew of patches need that API are sprinkled all over
the kernel, so they by necessity need to base on this nexus commit.

Essentially it happens when developers need an API from subsystem
A in place to do changes in subsystems B, C, D... Also they seldom have
patience to wait for a kernel cycle before making use of the API change,
instead one finger on the fastforward button at all times. (I don't blame them,
I am one of them.)

Typical cases:
<linux/mfd/*.h>
<dt-bindings/*.h>

I think Lee Jones could contribute to discussions around this, as he's
had the painful job to coordinate queue and quite a few of these hurdles
due to the nature of MFD as a connection nexus for misc.

One thing he does is queue an immutable topic branch, announce it and
let all affected subsystems pull it in, so that we (e.g. GPIO) can then
refactor or apply local fixes in "our" subsystem from that point, even during
the development cycle. It is pretty neat.

Yours,
Linus Walleij

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Olof Johansson]

On Mon, Apr 24, 2017 at 9:17 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
>> Might just be good to chat a bit about when exactly a topic branch is
>> called for, and when exactly merging through each separate tree is
>> better. I get a bit the feeling that merging through separate trees is
>> done to make sure platforms use all the infrastructure correctly
>> (which is the topic below), but it seems like DT managed to get there
>> without merging things stricly only through a DT tree.
>
> What has been mentioned about Kconfig symbols being merged in
> one place and then turned on in a merge commit is just part of it
> really. To me the big pain is always API/file dependencies.
>
> The typical case where we have to have a immutable topic branch
> is when there is a new API (or just a header file really) added in one
> patch and then a slew of patches need that API are sprinkled all over
> the kernel, so they by necessity need to base on this nexus commit.
>
> Essentially it happens when developers need an API from subsystem
> A in place to do changes in subsystems B, C, D... Also they seldom have
> patience to wait for a kernel cycle before making use of the API change,
> instead one finger on the fastforward button at all times. (I don't blame them,
> I am one of them.)
>
> Typical cases:
> <linux/mfd/*.h>
> <dt-bindings/*.h>
>
> I think Lee Jones could contribute to discussions around this, as he's
> had the painful job to coordinate queue and quite a few of these hurdles
> due to the nature of MFD as a connection nexus for misc.
>
> One thing he does is queue an immutable topic branch, announce it and
> let all affected subsystems pull it in, so that we (e.g. GPIO) can then
> refactor or apply local fixes in "our" subsystem from that point, even during
> the development cycle. It is pretty neat.

Yeah, Lee has been doing a good job there (even though we always
double-check about immutable branches to make the producer aware that
we've picked it up). The clk maintainers (Mike/Stephen) have been
doing a good job too where they tend to apply patches on a per-driver
branch that they keep immutable.

In the clk case we've been pushing back against the "add a branch
dependency just to add one numerical define use" that has been common
for incremental changes that affect clk and DT contents, instead
asking people to revisit with a follow-up patch either right after
-rc1 or next release.


-Olof

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Mon, Apr 24, 2017 at 10:29:02AM -0700, Olof Johansson wrote:
> On Mon, Apr 24, 2017 at 9:17 AM, Linus Walleij <linus.walleij@linaro.org> wrote:

> > One thing he does is queue an immutable topic branch, announce it and
> > let all affected subsystems pull it in, so that we (e.g. GPIO) can then
> > refactor or apply local fixes in "our" subsystem from that point, even during
> > the development cycle. It is pretty neat.

> Yeah, Lee has been doing a good job there (even though we always
> double-check about immutable branches to make the producer aware that

Yeah, I do the same thing where that comes up (mainly for regulator and
sometimes regmap).  Seems to work pretty well.

> we've picked it up). The clk maintainers (Mike/Stephen) have been
> doing a good job too where they tend to apply patches on a per-driver
> branch that they keep immutable.

That's what I do as well.  It's especially helpful if you discover a
need to do a cross merge after things have been applied, it means that
you probably already have something fairly sensible to send to the other
maintainers involved and don't need to rebase things or duplicate
commits.  Before I started doing this those things were always painful,
now I just need to sign a tag.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Lee Jones]

On Mon, 24 Apr 2017, Linus Walleij wrote:
> On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > Might just be good to chat a bit about when exactly a topic branch is
> > called for, and when exactly merging through each separate tree is
> > better. I get a bit the feeling that merging through separate trees is
> > done to make sure platforms use all the infrastructure correctly
> > (which is the topic below), but it seems like DT managed to get there
> > without merging things stricly only through a DT tree.
> 
> The typical case where we have to have a immutable topic branch
> is when there is a new API (or just a header file really) added in one
> patch and then a slew of patches need that API are sprinkled all over
> the kernel, so they by necessity need to base on this nexus commit.

[...]

> I think Lee Jones could contribute to discussions around this, as he's
> had the painful job to coordinate queue and quite a few of these hurdles
> due to the nature of MFD as a connection nexus for misc.
> 
> One thing he does is queue an immutable topic branch, announce it and
> let all affected subsystems pull it in, so that we (e.g. GPIO) can then
> refactor or apply local fixes in "our" subsystem from that point, even during
> the development cycle. It is pretty neat.

Multi-Function Devices (drivers/mfd) can waive a complicated web of
cross-subsystem/interdependent function calls, resources and time
sensitive H/W initialisation constraints.  Thus, when working with
such devices, the Maintainers of the children devices and I must work
together to avoid disruption to the user experience.

Our chosen method, or at least the one which causes the least pain, is
immutable branches.  Pull-requests to immutable branches are an
invaluable tool when coordination between 2 or more maintainers is
required.  The use-case does not always allow it, but we do try to
encapsulate all of the dependencies within a single branch, thus
minimising the chance of conflict during the merge-window.  My
MFD pull-request to Linus can contain between 1 and 7 immutable tags.

Although common place, immutable branches are still treated as the
last resort.  If patches can be taken via their respective subsystem
trees without fear of disruption, they are.  Contributors often
attempt to have their *new* cross-subsystem functionality taken in via
a single tree (requiring an immutable branch), purely because it's
convenient and the merge-time becomes deterministic, but we do not
allow that unless there are hard/unavoidable build-time dependencies.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Chris Mason]

On 04/18/2017 04:21 PM, Linus Torvalds wrote:
> On Tue, Apr 18, 2017 at 1:11 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>>
>> I'd recommend Ben Hutchings for the help and work he does with stable
>> kernel releases as well.  Those numbers don't show up in your tree, but
>> in the stable releases, he is up there at with the amount of effort and
>> help he provides me, and the users of the trees he maintains (3.2 and
>> 3.16 for Debian).  I figure the stable trees do tie into "process
>> improvements" for some discussions.
>
> Absolutely.  And as already mentioned, I'd like to extend it further
> downstream and actually have distro people. Not tons, but to get the
> discussion going about what works for them and in particular how (if?)
> we could integrate those closer.

What kind of questions did you have for the distros?  As a semi-distro 
kernel, we're happy to pitch in with content about bugs, performance, 
pulling in stable etc, but for the most part things have been smooth lately.

It's not completely regression free from a performance point of view, 
but that's more our fault for not getting our workload specific 
benchmarks into more hands.

We've also had some driver bug drama, but nothing that I would say shows 
a need for process changes across the board.

-chris

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Bart Van Assche]

On 04/19/17 12:55, James Bottomley wrote:
> On Wed, 2017-04-19 at 22:50 +0300, Laurent Pinchart wrote:
>> On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote:
>>> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote:
>>>> Agreed, for a maintainer summit to be useful, we need to have 
>>>> multiple sides present. Gathering core maintainers with key
>>>> representatives of the downstream communities around the table is 
>>>> great, but I think we would be missing one category whose opinion 
>>>> is equally important: kernel developers.
>>>>
>>>> When everything goes well developers can be represented by their
>>>> maintainers. That's the case where the process flows smoothly, so 
>>>> there isn't likely to be much to discuss. However, problems 
>>>> occurring in the maintenance process are likely to result in, if 
>>>> not conflicts, at least different views between maintainers and 
>>>> developers, in which case developers won't be represented at the
>>>> summit.
>>>>
>>>> I'm not sure how to handle that. I certainly don't want to 
>>>> increase the number of attendees to include key representatives 
>>>> of developers (and while I'd be very curious to see how they 
>>>> would be selected, I doubt it would work in practice), but I also 
>>>> believe we need to address this class of maintainership issues.
>>>
>>> I do agree that it would be a great thing to have a "bitch at
>>> maintainers" session where developers get to vent frustration at 
>>> how their patches are (or are _not_) accepted by maintainers.
>>>
>>> I know we've had issues in the VFS layer, with Al sometimes
>>> effectively dropping off the intenet for a time, for example.  And 
>>> I'm sure it happens elsewhere too, I'm just aware of the VFS side
>>> because it's one of the areas where I end up personally being a 
>>> secondary maintainer.
>>>
>>> But the problem with that "bitch at maintainers" thing is that I 
>>> can't for the life of me come up with a sane small set of people to 
>>> do that. So I don't see it happening ;(
>>
>> I currently don't have any good idea to make that happen either, but 
>> I'll keep thinking about it :-) More than bitching at maintainers, I 
>> believe that lots of developers, especially "smaller" or infrequent 
>> kernel contributors, are frustrated by maintainership issues that the 
>> related maintainers might not even be aware of.
> 
> Isn't it easy?  The Maintainers summit is going to be part of a larger
> kernel track within LinuxCon EU  (not that everyone plans on staying
> on, of course, but several will be).  Just put the bitch at Maintainers
> session in that as a round table, so any attendee of LinuxCon EU can
> come and complain if they want to.

We all know that the stability and the long-term success of the Linux
kernel strongly depend on how well kernel maintainers do their job. What
I noticed myself is that for some subsystems I contribute to (e.g.
block, SCSI and RDMA) maintainers provide feedback about patches within
a very reasonable time. For two other subsystems I contribute to it can
take weeks or months before adequate feedback is provided. Sorry but I
don't think that it is acceptable that it takes that long before
feedback is provided and hence that this is a topic that deserves to be
discussed during the maintainer summit.

Bart.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Guenter Roeck]

On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote:
> On 04/19/17 12:55, James Bottomley wrote:
> > On Wed, 2017-04-19 at 22:50 +0300, Laurent Pinchart wrote:
> >> On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote:
> >>> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote:
> >>>> Agreed, for a maintainer summit to be useful, we need to have 
> >>>> multiple sides present. Gathering core maintainers with key
> >>>> representatives of the downstream communities around the table is 
> >>>> great, but I think we would be missing one category whose opinion 
> >>>> is equally important: kernel developers.
> >>>>
> >>>> When everything goes well developers can be represented by their
> >>>> maintainers. That's the case where the process flows smoothly, so 
> >>>> there isn't likely to be much to discuss. However, problems 
> >>>> occurring in the maintenance process are likely to result in, if 
> >>>> not conflicts, at least different views between maintainers and 
> >>>> developers, in which case developers won't be represented at the
> >>>> summit.
> >>>>
> >>>> I'm not sure how to handle that. I certainly don't want to 
> >>>> increase the number of attendees to include key representatives 
> >>>> of developers (and while I'd be very curious to see how they 
> >>>> would be selected, I doubt it would work in practice), but I also 
> >>>> believe we need to address this class of maintainership issues.
> >>>
> >>> I do agree that it would be a great thing to have a "bitch at
> >>> maintainers" session where developers get to vent frustration at 
> >>> how their patches are (or are _not_) accepted by maintainers.
> >>>
> >>> I know we've had issues in the VFS layer, with Al sometimes
> >>> effectively dropping off the intenet for a time, for example.  And 
> >>> I'm sure it happens elsewhere too, I'm just aware of the VFS side
> >>> because it's one of the areas where I end up personally being a 
> >>> secondary maintainer.
> >>>
> >>> But the problem with that "bitch at maintainers" thing is that I 
> >>> can't for the life of me come up with a sane small set of people to 
> >>> do that. So I don't see it happening ;(
> >>
> >> I currently don't have any good idea to make that happen either, but 
> >> I'll keep thinking about it :-) More than bitching at maintainers, I 
> >> believe that lots of developers, especially "smaller" or infrequent 
> >> kernel contributors, are frustrated by maintainership issues that the 
> >> related maintainers might not even be aware of.
> > 
> > Isn't it easy?  The Maintainers summit is going to be part of a larger
> > kernel track within LinuxCon EU  (not that everyone plans on staying
> > on, of course, but several will be).  Just put the bitch at Maintainers
> > session in that as a round table, so any attendee of LinuxCon EU can
> > come and complain if they want to.
> 
> We all know that the stability and the long-term success of the Linux
> kernel strongly depend on how well kernel maintainers do their job. What
> I noticed myself is that for some subsystems I contribute to (e.g.
> block, SCSI and RDMA) maintainers provide feedback about patches within
> a very reasonable time. For two other subsystems I contribute to it can
> take weeks or months before adequate feedback is provided. Sorry but I
> don't think that it is acceptable that it takes that long before
> feedback is provided and hence that this is a topic that deserves to be
> discussed during the maintainer summit.
> 

Double edged sword.

You are right when it comes to a subsystem with active participants
who are willing to review patches.

On the other side, for a subsystem which has been declared "obscure"
and/or "obsolete" in public, it may well be that the maintainer is
the only person in the world looking at patches. I would argue
that you should give the maintainers of such subsystems a little
slack (or maybe even volunteer to review some patches ?).

Thanks,
Guenter

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote:

> I noticed myself is that for some subsystems I contribute to (e.g.
> block, SCSI and RDMA) maintainers provide feedback about patches within
> a very reasonable time. For two other subsystems I contribute to it can
> take weeks or months before adequate feedback is provided. Sorry but I
> don't think that it is acceptable that it takes that long before
> feedback is provided and hence that this is a topic that deserves to be
> discussed during the maintainer summit.

This comes up most years...  is a discussion likely to come up with
anything new that's concretely actionable?

That said a related thing that feels like it's definitely a maintainer
summit thing is getting new things into the kernel that somehow sit
between maintainers (new subsystems being the most obvious example) - we
do have a gap where people will negatively review things but won't
either take them or positively review them which can go on for very long
periods with people being just ignored (or worse just getting new people
popping up every once in a while with negative comments).  That's
obviously offputting for submitters, and can be especially bad if it's
coupled with other stuff like people taking on board the derogatory
comments that often get made about some segments of the industry.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Bart Van Assche]

On 04/25/17 09:56, Mark Brown wrote:
> On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote:
>> I noticed myself is that for some subsystems I contribute to (e.g.
>> block, SCSI and RDMA) maintainers provide feedback about patches within
>> a very reasonable time. For two other subsystems I contribute to it can
>> take weeks or months before adequate feedback is provided. Sorry but I
>> don't think that it is acceptable that it takes that long before
>> feedback is provided and hence that this is a topic that deserves to be
>> discussed during the maintainer summit.
>
> This comes up most years...  is a discussion likely to come up with
> anything new that's concretely actionable?

Hello Mark,

If priorities change over time and someone who had initially sufficient 
time to be a kernel maintainer and later on that changes that's 
something I can understand. But what I do not understand is if someone 
no longer has enough time to be a kernel maintainer why he or she does 
not look for help and e.g. asks someone who has the required skills and 
who is interested in this kind of work to become a co-maintainer?

Bart.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Geert Uytterhoeven]

On Wed, Apr 26, 2017 at 5:47 AM, Bart Van Assche
<Bart.VanAssche@sandisk.com> wrote:
> On 04/25/17 09:56, Mark Brown wrote:
>> On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote:
>>> I noticed myself is that for some subsystems I contribute to (e.g.
>>> block, SCSI and RDMA) maintainers provide feedback about patches within
>>> a very reasonable time. For two other subsystems I contribute to it can
>>> take weeks or months before adequate feedback is provided. Sorry but I
>>> don't think that it is acceptable that it takes that long before
>>> feedback is provided and hence that this is a topic that deserves to be
>>> discussed during the maintainer summit.
>>
>> This comes up most years...  is a discussion likely to come up with
>> anything new that's concretely actionable?
>
> Hello Mark,
>
> If priorities change over time and someone who had initially sufficient
> time to be a kernel maintainer and later on that changes that's
> something I can understand. But what I do not understand is if someone
> no longer has enough time to be a kernel maintainer why he or she does
> not look for help and e.g. asks someone who has the required skills and
> who is interested in this kind of work to become a co-maintainer?

He/she may not have enough time for/other priorities than looking for
a skilled replacement?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Dan Carpenter]

On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote:
> We all know that the stability and the long-term success of the Linux
> kernel strongly depend on how well kernel maintainers do their job. What
> I noticed myself is that for some subsystems I contribute to (e.g.
> block, SCSI and RDMA) maintainers provide feedback about patches within
> a very reasonable time. For two other subsystems I contribute to it can
> take weeks or months before adequate feedback is provided. Sorry but I
> don't think that it is acceptable that it takes that long before
> feedback is provided and hence that this is a topic that deserves to be
> discussed during the maintainer summit.
> 

It's Ok to wait weeks.  Months is not OK.

If maintainers are not reading their email then you can try forwarding
the patches through Andrew.

I feel like I haven't had such a huge problem with this recently...  Are
we talking about other arches besides x86 and ARM?  My patches are
normally simple is probably part of the difference.

regards,
dan carpenter

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Martin K. Petersen]

Dan,

> My patches are normally simple is probably part of the difference.

Patch complexity usually has something to do with it. In SCSI I deal
with simple patches right away. Other people are also willing to jump in
and review because the time commitment to do so is low.

It's much harder to get people to review intricate core changes because
they need a significant chunk of uninterrupted time. And that's a
precious resource.

Another gripe of mine wrt. big vs. small is that almost all vendor
driver updates come in the form of "30+ patches to update the driver to
version XYZ". Often a week before the merge window. And then they wonder
why nobody reviews them. Well, duh. That's a huge chunk of time for
somebody to commit.

It would be much better if they'd drop the arbitrary and pointless
"driver version XYZ" notion and just send a few patches per week.
Reviewers are much more inclined to go "Oh, I have 15 minutes now, let
me check my inbox". In most cases the reviews would also be more
thorough because you don't lose focus after patch number 7 and just
want this entire thing to be over before your brain turns into mush.

Anyway. Just being the devil's advocate here. It just seems there's a
consistent "maintainers are bad/lazy/unresponsive" theme going on. But
for better or for worse, patch submitters are often presenting their
work in ways that are completely indigestible. Not just to the
maintainers, but to the people willing to do reviews.

Not sure what we can do to address this? I often have big patch series
sitting tagged in my inbox for days/weeks while I chip away at them. But
the reality is that few, if any, reviewers do the same. If there is not
enough time to review a submission first time people see it in their
inbox, chances are that the review opportunity is lost forever.

And if nobody else reviews the patches the burden falls on me, making my
backlog even bigger.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Andrew Lunn]

> Another gripe of mine wrt. big vs. small is that almost all vendor
> driver updates come in the form of "30+ patches to update the driver to
> version XYZ". Often a week before the merge window. And then they wonder
> why nobody reviews them. Well, duh. That's a huge chunk of time for
> somebody to commit.

> Anyway. Just being the devil's advocate here. It just seems there's a
> consistent "maintainers are bad/lazy/unresponsive" theme going on. But
> for better or for worse, patch submitters are often presenting their
> work in ways that are completely indigestible.

What works well with netdev is that the maintainers simply NACK the
patches within a day and ask them to be submitted in smaller batches.

In my opinion, part of being a Maintainer is educating patch
submitters how the process should work and how best to present their
work so that it can be reviewed. It takes a bit of effort, but the
returns are worth it.

	Andrew

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Wed, Apr 26, 2017 at 03:47:13AM +0000, Bart Van Assche wrote:
> On 04/25/17 09:56, Mark Brown wrote:

> > This comes up most years...  is a discussion likely to come up with
> > anything new that's concretely actionable?

> If priorities change over time and someone who had initially sufficient 
> time to be a kernel maintainer and later on that changes that's 
> something I can understand. But what I do not understand is if someone 
> no longer has enough time to be a kernel maintainer why he or she does 
> not look for help and e.g. asks someone who has the required skills and 
> who is interested in this kind of work to become a co-maintainer?

You'd have to ask the relevant people...  based on the times I've looked
at problematic subsystems it often seems that either people have
completely vanished for whatever reason or there's very little other
interest in the subsystem so no obvious candidates.  I'm not saying that
there isn't a problem, I'm just saying that it's not new and it doesn't
seem like the situation changed much.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Wed, 2017-04-26 at 09:58 -0400, Martin K. Petersen wrote:
> Anyway. Just being the devil's advocate here. It just seems there's a
> consistent "maintainers are bad/lazy/unresponsive" theme going on. 
> But for better or for worse, patch submitters are often presenting 
> their work in ways that are completely indigestible. Not just to the
> maintainers, but to the people willing to do reviews.

I definitely agree with this.  Complain about the maintainer because my
patch hasn't gone in is fairly common pattern.

> Not sure what we can do to address this? I often have big patch
> series sitting tagged in my inbox for days/weeks while I chip away at
> them.  But the reality is that few, if any, reviewers do the same. If
> there is not enough time to review a submission first time people see
> it in their inbox, chances are that the review opportunity is lost
> forever.

One thing we tried a while ago, which perhaps we should discuss
resurrecting is the idea of holding up patches until the submitter has
enough current reviews.  At base this means for two driver patches,
each submitter reviews the other patches.

When we tried this in SCSI we had mixed results.  The problem is that
holding up patches in this way causes even more complaints, so you have
to be really disciplined about it (and up front about the reasons). 
 However, I still think finding ways of encouraging submitters (who
obviously should understand the code) to participate equally in the
review process seems to be the scalable way forwards ... the problem is
how to do it without causing huge ructions.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jiri Kosina]

On Wed, 26 Apr 2017, James Bottomley wrote:

> When we tried this in SCSI we had mixed results.  The problem is that
> holding up patches in this way causes even more complaints, so you have
> to be really disciplined about it (and up front about the reasons). 

Another problem is that sending e-mail containing 'Reviewed-by:' is way 
too easy if it's being motivated by something else than a real desire to 
actually perform the review.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Wed, 2017-04-26 at 16:34 +0200, Jiri Kosina wrote:
> On Wed, 26 Apr 2017, James Bottomley wrote:
> 
> > When we tried this in SCSI we had mixed results.  The problem is 
> > that holding up patches in this way causes even more complaints, so 
> > you have to be really disciplined about it (and up front about the
> > reasons).
 
> 
> Another problem is that sending e-mail containing 'Reviewed-by:' is 
> way too easy if it's being motivated by something else than a real 
> desire to actually perform the review.

Agreed, but I think you'll find most maintainers have a "trust factor"
for reviewers.  Perhaps we should discuss how we arrive at this and how
we should make it more public.  The way I often deal with less trusted
reviewers is to redo their review and point out all the things they
missed and ask them not to come back until they can be more thorough.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[David Miller]

From: Mark Brown <broonie@kernel.org>
Date: Wed, 26 Apr 2017 15:21:49 +0100

> On Wed, Apr 26, 2017 at 03:47:13AM +0000, Bart Van Assche wrote:
>> On 04/25/17 09:56, Mark Brown wrote:
> 
>> > This comes up most years...  is a discussion likely to come up with
>> > anything new that's concretely actionable?
> 
>> If priorities change over time and someone who had initially sufficient 
>> time to be a kernel maintainer and later on that changes that's 
>> something I can understand. But what I do not understand is if someone 
>> no longer has enough time to be a kernel maintainer why he or she does 
>> not look for help and e.g. asks someone who has the required skills and 
>> who is interested in this kind of work to become a co-maintainer?
> 
> You'd have to ask the relevant people...  based on the times I've looked
> at problematic subsystems it often seems that either people have
> completely vanished for whatever reason or there's very little other
> interest in the subsystem so no obvious candidates.  I'm not saying that
> there isn't a problem, I'm just saying that it's not new and it doesn't
> seem like the situation changed much.

Often people just don't want to let go and give up "control" of
something they've watched over for a long period of time.

I think we suffer from this a lot.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Bart Van Assche]

On Wed, 2017-04-26 at 11:42 +0300, Dan Carpenter wrote:
> It's Ok to wait weeks.  Months is not OK.
> 
> If maintainers are not reading their email then you can try forwarding
> the patches through Andrew.
> 
> I feel like I haven't had such a huge problem with this recently...  Are
> we talking about other arches besides x86 and ARM?  My patches are
> normally simple is probably part of the difference.

Hello Dan,

In my e-mail I was referring to the code under drivers/target and
drivers/md/dm*. With all due respect, I don't think that Andrew is familiar
enough with these code bases to accept patches for these subsystems.

Bart.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Wed, Apr 26, 2017 at 10:51:23AM -0400, David Miller wrote:

> > You'd have to ask the relevant people...  based on the times I've looked
> > at problematic subsystems it often seems that either people have
> > completely vanished for whatever reason or there's very little other
> > interest in the subsystem so no obvious candidates.  I'm not saying that
> > there isn't a problem, I'm just saying that it's not new and it doesn't
> > seem like the situation changed much.

> Often people just don't want to let go and give up "control" of
> something they've watched over for a long period of time.

> I think we suffer from this a lot.

Yeah, that's definitely a part of it too - it often goes hand in hand
with the lack of other reviewers thing as the two can easily feed off
each other, it's a lot easier to let go if there's someone to hand
things over to but if things aren't working well that can be
discouraging to potential new reviewers.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On April 26, 2017 11:02:39 AM EDT, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote:
>On Wed, 2017-04-26 at 11:42 +0300, Dan Carpenter wrote:
>> It's Ok to wait weeks.  Months is not OK.
>> 
>> If maintainers are not reading their email then you can try
>forwarding
>> the patches through Andrew.
>> 
>> I feel like I haven't had such a huge problem with this recently... 
>Are
>> we talking about other arches besides x86 and ARM?  My patches are
>> normally simple is probably part of the difference.
>
>Hello Dan,
>
>In my e-mail I was referring to the code under drivers/target and
>drivers/md/dm*. With all due respect, I don't think that Andrew is
>familiar
>enough with these code bases to accept patches for these subsystems.

I think what Dan is referring to is that Andrew used to have an override the maintainer role.   He'd take a patch and send out the usual email forcing a nak if it shouldn't go upstream.  I.e forcing at least a response.  You don't need more than a mechanical review to do this because you're challenging the maintainer to respond. 

James

>Bart.
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Wed, Apr 26, 2017 at 11:25:12AM -0400, James Bottomley wrote:
> On April 26, 2017 11:02:39 AM EDT, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote:

> >In my e-mail I was referring to the code under drivers/target and
> >drivers/md/dm*. With all due respect, I don't think that Andrew is
> >familiar
> >enough with these code bases to accept patches for these subsystems.

> I think what Dan is referring to is that Andrew used to have an
> override the maintainer role.   He'd take a patch and send out the
> usual email forcing a nak if it shouldn't go upstream.  I.e forcing at
> least a response.  You don't need more than a mechanical review to do
> this because you're challenging the maintainer to respond. 

Or to put it another way at some point if nobody else is doing any work
in the area then whoever is becomes our best expert on it.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Martin K. Petersen]

Andrew,

> What works well with netdev is that the maintainers simply NACK the
> patches within a day and ask them to be submitted in smaller batches.
>
> In my opinion, part of being a Maintainer is educating patch
> submitters how the process should work and how best to present their
> work so that it can be reviewed. It takes a bit of effort, but the
> returns are worth it.

It's not for lack of trying. But the response typically that "our
internal process/version number/qual cycle/release schedule is more
important than getting the patches upstream".

I think that's probably more of an issue in SCSI than in other
subsystems due to enterprise manufacturer inertia...

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Jani Nikula]

On Wed, 26 Apr 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> Agreed, but I think you'll find most maintainers have a "trust factor"
> for reviewers.  Perhaps we should discuss how we arrive at this and how
> we should make it more public.  The way I often deal with less trusted
> reviewers is to redo their review and point out all the things they
> missed and ask them not to come back until they can be more thorough.

I think that's also a bit harsh, because I think the only way to become
a better reviewer is to... review. I know it's hard to balance being
welcoming to new reviewers and ensuring the patches do get proper review
in the end.

Certainly one thing that increases my trust in a review is the amount of
review comments on the patch, even if there's a Reviewed-by at the
end. Basically any hints that the reviewer has actually thought about
the changes.

On a related note, as maintainers I think we need to put more attention
to recording the review credits in the commits. It's not unusual for
review to be more work than writing the patch. The patch authors may be
new contributors, or just looking at their specific use case, but the
reviewer should look at the big picture. I think Jon will start tracking
reviews more regularly, like he did for v4.11 stats [1], but obviously
the stats are only as good as the input.


BR,
Jani.


[1] https://lwn.net/Articles/720336/


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Lee Jones]

On Thu, 27 Apr 2017, Jani Nikula wrote:
> On Wed, 26 Apr 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > Agreed, but I think you'll find most maintainers have a "trust factor"
> > for reviewers.  Perhaps we should discuss how we arrive at this and how
> > we should make it more public.  The way I often deal with less trusted
> > reviewers is to redo their review and point out all the things they
> > missed and ask them not to come back until they can be more thorough.
> 
> I think that's also a bit harsh, because I think the only way to become
> a better reviewer is to... review. I know it's hard to balance being
> welcoming to new reviewers and ensuring the patches do get proper review
> in the end.

I'm inclined to agree, this is a harsh approach.  My personal method
is to allow anyone to review, regardless of their credibility/trust
status.  I make a point not to hamper or criticise anyone that's
genuinely tying to help, unless of f course they are dishing out bogus
review comments, then those will need addressing, but only picking up
even say 10% of the issues really isn't a problem.  It doesn't matter
how many points are picked-up or missed, we as Maintainers can always
conduct an additional review or one in parallel.

I find additional reviewers particularly helpful if I'm overloaded,
since I can then insist that the contributor fixes all outstanding
review comments before I conduct my, hopefully thorough, review. 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blogs

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Hannes Reinecke]

On 04/27/2017 12:41 PM, Lee Jones wrote:
> On Thu, 27 Apr 2017, Jani Nikula wrote:
>> On Wed, 26 Apr 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>>> Agreed, but I think you'll find most maintainers have a "trust factor"
>>> for reviewers.  Perhaps we should discuss how we arrive at this and how
>>> we should make it more public.  The way I often deal with less trusted
>>> reviewers is to redo their review and point out all the things they
>>> missed and ask them not to come back until they can be more thorough.
>>
>> I think that's also a bit harsh, because I think the only way to become
>> a better reviewer is to... review. I know it's hard to balance being
>> welcoming to new reviewers and ensuring the patches do get proper review
>> in the end.
> 
> I'm inclined to agree, this is a harsh approach.  My personal method
> is to allow anyone to review, regardless of their credibility/trust
> status.  I make a point not to hamper or criticise anyone that's
> genuinely tying to help, unless of f course they are dishing out bogus
> review comments, then those will need addressing, but only picking up
> even say 10% of the issues really isn't a problem.  It doesn't matter
> how many points are picked-up or missed, we as Maintainers can always
> conduct an additional review or one in parallel.
> 
> I find additional reviewers particularly helpful if I'm overloaded,
> since I can then insist that the contributor fixes all outstanding
> review comments before I conduct my, hopefully thorough, review. 
> 
Indeed. From my POV the biggest problem is a shortage of reviewers, and
we should be working on getting that resolved.
In fact, most developers I'm working with simply are too scared to do
any reviews, feeling as they do not being qualified enough.
If we take the abovementioned route that's a sure way of putting them
off reviewing for good.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Thu, 2017-04-27 at 13:02 +0200, Hannes Reinecke wrote:
> On 04/27/2017 12:41 PM, Lee Jones wrote:
> > On Thu, 27 Apr 2017, Jani Nikula wrote:
> > > On Wed, 26 Apr 2017, James Bottomley <
> > > James.Bottomley@HansenPartnership.com> wrote:
> > > > Agreed, but I think you'll find most maintainers have a "trust 
> > > > factor" for reviewers.  Perhaps we should discuss how we arrive 
> > > > at this and how we should make it more public.  The way I often 
> > > > deal with less trusted reviewers is to redo their review and 
> > > > point out all the things they missed and ask them not to come 
> > > > back until they can be more thorough.
> > > 
> > > I think that's also a bit harsh, because I think the only way to 
> > > become a better reviewer is to... review. I know it's hard to 
> > > balance being welcoming to new reviewers and ensuring the patches 
> > > do get proper review in the end.
> > 
> > I'm inclined to agree, this is a harsh approach.  My personal 
> > method is to allow anyone to review, regardless of their 
> > credibility/trust status.  I make a point not to hamper or 
> > criticise anyone that's genuinely tying to help, unless of f course 
> > they are dishing out bogus review comments, then those will need 
> > addressing, but only picking up even say 10% of the issues really 
> > isn't a problem.  It doesn't matter how many points are picked-up 
> > or missed, we as Maintainers can always conduct an additional
> > review or one in parallel.

OK, so I should clarify that where I'm coming from is that I want not
to have to review something if someone else has already done so.  I
suppose I should add that you mostly get these type of comments from me
if I expected I could rely on your review but a random inspection found
significant issues.

> > I find additional reviewers particularly helpful if I'm overloaded,
> > since I can then insist that the contributor fixes all outstanding
> > review comments before I conduct my, hopefully thorough, review. 
> > 
> Indeed. From my POV the biggest problem is a shortage of reviewers, 
> and we should be working on getting that resolved.

So wouldn't making review a precondition for patch acceptance be a
strategy for at least helping with this?

> In fact, most developers I'm working with simply are too scared to do
> any reviews, feeling as they do not being qualified enough.
> If we take the abovementioned route that's a sure way of putting them
> off reviewing for good.

I actually don't really believe people are afraid to review code.  I
think mostly (particularly in SCSI) they've got their hands full with
constructing submissions and don't want to expend the additional
bandwidth.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Wolfram Sang]

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


> On a related note, as maintainers I think we need to put more attention
> to recording the review credits in the commits. It's not unusual for
> review to be more work than writing the patch. The patch authors may be
> new contributors, or just looking at their specific use case, but the
> reviewer should look at the big picture. I think Jon will start tracking
> reviews more regularly, like he did for v4.11 stats [1], but obviously
> the stats are only as good as the input.

I fully agree to this. I hacked git-request-pull to include a list of
people who reviewed or tested patches. The patch is quite a hack,
though. As it works for me(tm) nonetheless, I finally set up a repo
where I will put such snippets which help me in maintaining my
subsystem. And I started the latest version of said patch a minute ago.
So, if other people are interested, it should be more accessible now:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/snippets.git

To get you an idea, here is some example output. More details can be
found in the patch description itself:

=== standard pull-request

The following changes since commit
a121103c922847ba5010819a3f250f1f7fc84ab8:

...

Vlad Tsyrklevich (1):
      i2c: fix kernel memory disclosure in dev interface

=== new stuff starts here

with much appreciated quality assurance from
----------------------------------------------------------------
Andy Shevchenko (1):
      (Rev.) i2c: piix4: Avoid race conditions with IMC

Benjamin Tissoires (1):
      (Test) i2c: do not enable fall back to Host Notify by default

Vladimir Zapolskiy (1):
      (Rev.) i2c: print correct device invalid address

=== diffstat, ...


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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Rafael J. Wysocki]

On Thursday, April 27, 2017 10:17:58 AM James Bottomley wrote:
> On Thu, 2017-04-27 at 13:02 +0200, Hannes Reinecke wrote:
> > On 04/27/2017 12:41 PM, Lee Jones wrote:
> > > On Thu, 27 Apr 2017, Jani Nikula wrote:
> > > > On Wed, 26 Apr 2017, James Bottomley <
> > > > James.Bottomley@HansenPartnership.com> wrote:
> > > > > Agreed, but I think you'll find most maintainers have a "trust 
> > > > > factor" for reviewers.  Perhaps we should discuss how we arrive 
> > > > > at this and how we should make it more public.  The way I often 
> > > > > deal with less trusted reviewers is to redo their review and 
> > > > > point out all the things they missed and ask them not to come 
> > > > > back until they can be more thorough.
> > > > 
> > > > I think that's also a bit harsh, because I think the only way to 
> > > > become a better reviewer is to... review. I know it's hard to 
> > > > balance being welcoming to new reviewers and ensuring the patches 
> > > > do get proper review in the end.
> > > 
> > > I'm inclined to agree, this is a harsh approach.  My personal 
> > > method is to allow anyone to review, regardless of their 
> > > credibility/trust status.  I make a point not to hamper or 
> > > criticise anyone that's genuinely tying to help, unless of f course 
> > > they are dishing out bogus review comments, then those will need 
> > > addressing, but only picking up even say 10% of the issues really 
> > > isn't a problem.  It doesn't matter how many points are picked-up 
> > > or missed, we as Maintainers can always conduct an additional
> > > review or one in parallel.
> 
> OK, so I should clarify that where I'm coming from is that I want not
> to have to review something if someone else has already done so.  I
> suppose I should add that you mostly get these type of comments from me
> if I expected I could rely on your review but a random inspection found
> significant issues.

Right, but this is not a black-and-white situation IMO.

Reviewers may overlook things even though they do their best and I guess that
happens to everyone occasionally.

One way to look at code review is as advice in a decision making process.
Of course, you are more likely to listen to people who tend to give you good
advice, but then they may not be right this time around and the decision
is for you to make anyway.

> > > I find additional reviewers particularly helpful if I'm overloaded,
> > > since I can then insist that the contributor fixes all outstanding
> > > review comments before I conduct my, hopefully thorough, review. 
> > > 
> > Indeed. From my POV the biggest problem is a shortage of reviewers, 
> > and we should be working on getting that resolved.
> 
> So wouldn't making review a precondition for patch acceptance be a
> strategy for at least helping with this?

I would be very careful about setting rules like that unless you absoultely
believe that you'll never need to break them, whatever the reason.

OTOH if people realize that doing review generally helps their patches to be
accepted, that may actually work. :-)

> > In fact, most developers I'm working with simply are too scared to do
> > any reviews, feeling as they do not being qualified enough.
> > If we take the abovementioned route that's a sure way of putting them
> > off reviewing for good.
> 
> I actually don't really believe people are afraid to review code.  I
> think mostly (particularly in SCSI) they've got their hands full with
> constructing submissions and don't want to expend the additional
> bandwidth.

Right.

There needs to be a clear benefit for the reviewer and ideally such that can
be presented to their management as a good deal.  Today, the perceived value
of code changes going in is much higher and people allocate their time
accordingly.

Thanks,
Rafael

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Daniel Vetter]

[Back from a bit of vacation, so I'm just jumping into the middle of
the cross-subsystem/invariant topic branch discussion. I read all the
other mails, but this seems most relevant.]

On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> wrote:
> Although common place, immutable branches are still treated as the
> last resort.  If patches can be taken via their respective subsystem
> trees without fear of disruption, they are.  Contributors often
> attempt to have their *new* cross-subsystem functionality taken in via
> a single tree (requiring an immutable branch), purely because it's
> convenient and the merge-time becomes deterministic, but we do not
> allow that unless there are hard/unavoidable build-time dependencies.

Honest question, why exactly?

At a quick ignorant glance this seems to trade contributor time
against maintainer time, which in my opinion means you should ramp up
your maintainer training and mentoring to have much more maintainer
time available and make contributing to upstream more attractive. But
drm != other subsystems, I'd like to hear more of why you picked this
tradeoff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Sat, 2017-04-29 at 23:00 +0200, Daniel Vetter wrote:
> [Back from a bit of vacation, so I'm just jumping into the middle of
> the cross-subsystem/invariant topic branch discussion. I read all the
> other mails, but this seems most relevant.]
> 
> On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org>
> wrote:
> > Although common place, immutable branches are still treated as the
> > last resort.  If patches can be taken via their respective 
> > subsystem trees without fear of disruption, they are.  Contributors 
> > often attempt to have their *new* cross-subsystem functionality 
> > taken in via a single tree (requiring an immutable branch), purely 
> > because it's convenient and the merge-time becomes deterministic, 
> > but we do not allow that unless there are hard/unavoidable build
> > -time dependencies.
> 
> Honest question, why exactly?

Because if you take a patch for, say SCSI, through your tree it
potentially becomes a big pain for everyone if we pick up a conflict. 
 The conflict isn't seen until linux-next finds it because the
conflicting patch is in your tree not mine (and SCSI contributors
mostly build against the SCSI tree) then Stephen has to come up with a
merge and we have to validate it and send it on to Linus as a
recommendation at merge window time.

Another good reason for not taking patches to subsystems outside yours
are that you're not necessarily an expert in whatever subsystem it is,
so a patch would get a better review cycle going through the correct
subsystem tree.

There are good reasons to take on this pain, like the conflicting patch
depends on something else that's in your tree but not in mine, so
there's no clean way to split it up and thus it makes sense to take it
through your tree and just handle the conflicts as they arise but
absent that the rule should be that patches to a subsystem go through
its tree.

> At a quick ignorant glance this seems to trade contributor time
> against maintainer time, which in my opinion means you should ramp up
> your maintainer training and mentoring to have much more maintainer
> time available and make contributing to upstream more attractive. But
> drm != other subsystems, I'd like to hear more of why you picked this
> tradeoff.

It's not just maintainer time ... taking patches outside your subsystem
should always have a good reason because it's not just a
training/tooling issue; you're potentially impacting some other
subsystem by this action.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown]

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

On Sat, Apr 29, 2017 at 02:39:31PM -0700, James Bottomley wrote:
> On Sat, 2017-04-29 at 23:00 +0200, Daniel Vetter wrote:
> > On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org>

> > > Although common place, immutable branches are still treated as the
> > > last resort.  If patches can be taken via their respective 
> > > subsystem trees without fear of disruption, they are.  Contributors 
> > > often attempt to have their *new* cross-subsystem functionality 
> > > taken in via a single tree (requiring an immutable branch), purely 
> > > because it's convenient and the merge-time becomes deterministic, 
> > > but we do not allow that unless there are hard/unavoidable build
> > > -time dependencies.

> > Honest question, why exactly?

[Snip a bunch of good reasons from James]

> > At a quick ignorant glance this seems to trade contributor time
> > against maintainer time, which in my opinion means you should ramp up
> > your maintainer training and mentoring to have much more maintainer
> > time available and make contributing to upstream more attractive. But
> > drm != other subsystems, I'd like to hear more of why you picked this
> > tradeoff.

> It's not just maintainer time ... taking patches outside your subsystem
> should always have a good reason because it's not just a
> training/tooling issue; you're potentially impacting some other
> subsystem by this action.

The other thing is that no matter how good the maintainers are at
handling cross tree stuff there's always going to be some cost to the
submitter even if it's just delays as the maintainers talk to each
other.  The less coordination is needed the more chance there is that
things will go smoothly.

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

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Olof Johansson]

On Sat, Apr 29, 2017 at 2:00 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> [Back from a bit of vacation, so I'm just jumping into the middle of
> the cross-subsystem/invariant topic branch discussion. I read all the
> other mails, but this seems most relevant.]
>
> On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> Although common place, immutable branches are still treated as the
>> last resort.  If patches can be taken via their respective subsystem
>> trees without fear of disruption, they are.  Contributors often
>> attempt to have their *new* cross-subsystem functionality taken in via
>> a single tree (requiring an immutable branch), purely because it's
>> convenient and the merge-time becomes deterministic, but we do not
>> allow that unless there are hard/unavoidable build-time dependencies.
>
> Honest question, why exactly?
>
> At a quick ignorant glance this seems to trade contributor time
> against maintainer time, which in my opinion means you should ramp up
> your maintainer training and mentoring to have much more maintainer
> time available and make contributing to upstream more attractive. But
> drm != other subsystems, I'd like to hear more of why you picked this
> tradeoff.

As mentioned already, we've seen too many messes caused by multiple
people stepping on each other. When you merge a mixed-contents branch
through another subsystem you have to gamble on anyone else not
touching anything near it.

Worst case possible is refactorings of code made by people at the same
time, with the almost-as-bad-case of one side refactoring, the other
one adding something new. And given how refactoring-happy DRM is, I'm
extremely hesitant to see ARM contents merged through there.

Another reason for that is that it's pretty common to have for example
media and graphics handled by separate teams from main platform code
(both in corporate land as well as on the community side). Having two
separate teams work on the same piece of code means that even though
_you_ say it's OK to merge through a different tree, the platform
maintainer on the other team might have different plans for that code.

Yes, there's some overhead in dealing with this. Most of it is pushed
down to the per-platform level, so there's no need to coordinate all
the way up the maintainer path in many cases. Main exception is
usually new contributors/platforms where we keep an extra eye on
things as new people get used to their roles, build up experience,
etc.


-Olof

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Lee Jones]

On Sat, 29 Apr 2017, Daniel Vetter wrote:

> [Back from a bit of vacation, so I'm just jumping into the middle of
> the cross-subsystem/invariant topic branch discussion. I read all the
> other mails, but this seems most relevant.]
> 
> On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > Although common place, immutable branches are still treated as the
> > last resort.  If patches can be taken via their respective subsystem
> > trees without fear of disruption, they are.  Contributors often
> > attempt to have their *new* cross-subsystem functionality taken in via
> > a single tree (requiring an immutable branch), purely because it's
> > convenient and the merge-time becomes deterministic, but we do not
> > allow that unless there are hard/unavoidable build-time dependencies.
> 
> Honest question, why exactly?
> 
> At a quick ignorant glance this seems to trade contributor time
> against maintainer time, which in my opinion means you should ramp up
> your maintainer training and mentoring to have much more maintainer
> time available and make contributing to upstream more attractive. But
> drm != other subsystems, I'd like to hear more of why you picked this
> tradeoff.

It looks like James et. al. have provided some pretty good technical
reasons as to why taking patches via their associated subsystem repos
is *always* preferred, so I will not labour this point.  However I
will provide a frank answer to your trading Maintainer for Contributor
time query.

To be candid, you're right we do that, and it's exactly what we
should be doing.  There are a couple of reasons for this:

The first is a simple matter of time related mathematics.  Taking an
average over the past 10 releases, MFD and Backlight had ~30 unique
submitters per release.  If even some of them managed to get
themselves into habits which cost me more time than it already does
to Maintain the subsystems, then either the Maintainership or my
employment role would be negatively impacted.  I view it better to
cost each Contributor 30 mins, than it to cost me 30 mins multiplied
by the amount of Contributors. Moreover, most Contributors are doing
so *as part* of their employment role, where-as myself and a great
many other Maintainers are operating *as well as*, or outside of
ours.

Secondly, this is about Contributor training and the encouragement of
good practices from the outset; patch separation, expert reviews,
conflict mitigation, bisection preservation, etc etc.  If we train and
arm the Contributors of today, we inherently encourage the Maintainers
of tomorrow.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

Ok, I'm re-starting this thread because it's been about a month of
quiet and nothing has really changed. James asked me to do another
email (but during the merge window, so I was busy) and today Thorsten
Leemhuis emailed about regression tracking issues, which just reminded
me to get this going again.

Removed everybody from the cc list except for David, because I still
want him to give an alternate for the networking subsystem (unless,
wonder of wonders, you're planning to be in Prague in October,
David?).

But the basic list that _I_ would like to see hasn't changed. That
doesn't mean that this should be "The List", but I think it's just
time to pass it over the wall to Ted?James?whoever is working on the
non-maintainer parts of the Kernel Summit.

One open question mark that James mentioned is just he vendor people -
particularly if they end up being KS sponsors. I have actually
traditionally liked the talks from vendors when they talk about their
issues (as long as they were actual technical talks, not the marketing
stuff - that's been a disaster), but I know some people found them
annoying. But I think that is partly organizational and ends up
involving Angela etc. We've always had sponsor people at the KS, I
would not mind if they ended up having double roles as sponsor people
with actual maintainer issues that they'd like to bring up.

Anyway, the top-ten maintainers haven't changed, and this just
reflects the "Dave Airlie suggests Daniel Vetter as a replacement".
Davem, your name remains on that list because you didn't suggest
alternatives..

  David Miller                  networking and network drivers
  Greg KH                       stable and misc drivers
  Daniel Vetter                 drm (Dave Airlie)
  Ingo Molnar                   x86 and core
  Mauro Carvalho Chehab         media drivers
  Arnd Bergmann                 arm and misc arch support
  Andrew Morton                 misc core
  Michael Ellerman              powerpc
  Takashi Iwai                  sound (and SuSE)
  Doug Ledford                  rdma

and I think any of those except probably Greg can suggest alternatives.

On top of those, I had me, stable and linux-next:

  Linus Torvalds
  Ben Hutchings                 stable, suggested by Greg
  Stephen Rothwell              linux-next

and that's kind of the "core maintainer" list. The rest of the names
are more tentative, in the sense that they are suggestions for the
kinds of areas that aren't directly touched by the above. Like:

 - the TAB people and KS people themselves. You know who you are, and
you're probably already on this list.

   I think there's a fair amount of overlap with this group and the
developers, but it might be worth looking exactly for those kinds of
"overlap" people.

 - Infrastructure:

   Konstantin Ryabitsev         k.org
   Fengguang Wu                 kernel test robot
   Steven Rostedt               ktest
   Shuah Khan                   tools/testing
   Thorsten Leemhuis            regression tracking
   Jonathan Corbet              documentaion
   .. and syzcaller/KASAN people?

 - Security:

   Andy Lutomirski              security and core
   Kees Cook                    security
   James Morris                 security subsystem

 - Distro people:

   Laura Abbott                 Fedora
   Jiri Kosina (MM? JM?)        Suse
   Rom Lemarchand               Android

 - Filesystems?

   Al Viro                      vfs process
   Darrick Wong                 xfs
   Ted Ts'o                     ext4

 - Block layer:

   Christoph Hellwig             also rdma and taste
   James Bottomley
   Jens Axboe

and I suspect picking people from these "misc" groups is at least
partly about the *other* days and who is in Prague anyway..

And again, there's the whole vendor/sponsor thing, ie facebook,
google, hw vendors etc.

I tried to gather up names as they flew past when I thought they fit
the maintainership agenda, but I was also trying to keep this
particular list fairly minimal. I suspect we'll see

                  Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Randy Dunlap]

On 05/23/17 10:58, Linus Torvalds wrote:
> 
> One open question mark that James mentioned is just he vendor people -
> particularly if they end up being KS sponsors. I have actually
> traditionally liked the talks from vendors when they talk about their
> issues (as long as they were actual technical talks, not the marketing
> stuff - that's been a disaster), but I know some people found them
> annoying. But I think that is partly organizational and ends up
> involving Angela etc. We've always had sponsor people at the KS, I
> would not mind if they ended up having double roles as sponsor people
> with actual maintainer issues that they'd like to bring up.
> 

I think that the distros are important, but sponsors are largely either
distros or huge (yuge) users, so they are also important (technical, not
marketing).

> Anyway, the top-ten maintainers haven't changed, and this just
> reflects the "Dave Airlie suggests Daniel Vetter as a replacement".
> Davem, your name remains on that list because you didn't suggest
> alternatives..
> 
>   David Miller                  networking and network drivers
>   Greg KH                       stable and misc drivers
				+ usb and staging
>   Daniel Vetter                 drm (Dave Airlie)
>   Ingo Molnar                   x86 and core
>   Mauro Carvalho Chehab         media drivers
>   Arnd Bergmann                 arm and misc arch support
>   Andrew Morton                 misc core
				plus MM; need more MM?

>   Michael Ellerman              powerpc
>   Takashi Iwai                  sound (and SuSE)
>   Doug Ledford                  rdma
> 
> and I think any of those except probably Greg can suggest alternatives.
> 
> On top of those, I had me, stable and linux-next:
> 
>   Linus Torvalds
>   Ben Hutchings                 stable, suggested by Greg
>   Stephen Rothwell              linux-next
> 
> and that's kind of the "core maintainer" list. The rest of the names
> are more tentative, in the sense that they are suggestions for the
> kinds of areas that aren't directly touched by the above. Like:
> 
>  - the TAB people and KS people themselves. You know who you are, and
> you're probably already on this list.
> 
>    I think there's a fair amount of overlap with this group and the
> developers, but it might be worth looking exactly for those kinds of
> "overlap" people.
> 
>  - Infrastructure:
> 
>    Konstantin Ryabitsev         k.org
>    Fengguang Wu                 kernel test robot
>    Steven Rostedt               ktest
>    Shuah Khan                   tools/testing
>    Thorsten Leemhuis            regression tracking
>    Jonathan Corbet              documentaion
>    .. and syzcaller/KASAN people?
> 
>  - Security:
> 
>    Andy Lutomirski              security and core
>    Kees Cook                    security
>    James Morris                 security subsystem
> 
>  - Distro people:
> 
>    Laura Abbott                 Fedora
>    Jiri Kosina (MM? JM?)        Suse
>    Rom Lemarchand               Android
> 
>  - Filesystems?
> 
>    Al Viro                      vfs process
>    Darrick Wong                 xfs
>    Ted Ts'o                     ext4
> 
>  - Block layer:
> 
>    Christoph Hellwig             also rdma and taste
:)

>    James Bottomley
>    Jens Axboe

I would probably add some power management rep.
Otherwise it looks about right to me as an observer.

-- 
~Randy

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Thomas Gleixner]

On Tue, 23 May 2017, Linus Torvalds wrote:
> I tried to gather up names as they flew past when I thought they fit
> the maintainership agenda, but I was also trying to keep this
> particular list fairly minimal. I suspect we'll see

I'm probably late, but I would like to add myself to that list. As RT (and
upstream) maintainer I'm pretty involved in large scale overhauls and
restructuring which is often enough a process issue.

Thanks,

	Thomas

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

On Tue, 2017-05-23 at 10:58 -0700, Linus Torvalds wrote:
> One open question mark that James mentioned is just he vendor people 
> - particularly if they end up being KS sponsors. I have actually
> traditionally liked the talks from vendors when they talk about their
> issues (as long as they were actual technical talks, not the 
> marketing stuff - that's been a disaster), but I know some people 
> found them annoying. But I think that is partly organizational and 
> ends up involving Angela etc. We've always had sponsor people at the 
> KS, I would not mind if they ended up having double roles as sponsor 
> people with actual maintainer issues that they'd like to bring up.

I'm happy to try to wrangle interesting and highly technical vendor
talks.  I believe the current time plan for the maintainer summit is
half a day (is this correct?), so I propose we do vendor talks in the
other half of the day.  That way people who aren't interested can take
the afternoon or morning (depending where people want it in the
timetable) off to see Prague.

James

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Tue, May 23, 2017 at 11:47 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> I'm probably late, but I would like to add myself to that list. As RT (and
> upstream) maintainer I'm pretty involved in large scale overhauls and
> restructuring which is often enough a process issue.

So I certainly have no objection, but I think we should strive to have
something approaching a "process" for the picking.

I assume there's an actual official KS organizing committee, although
I have no idea who would be on it, except for the presumed usual
suspects (ie Ted and James).

And I would suggest that in order to make it easier on them, _and_ to
actually also have an agenda in place when we show up in October,
people who want to nominate themselves (or somebody else, for that
matter), actually write a little blurb about what they want to bring
up for the agenda.

That would help both the selection committee and the agenda.

In the "what to bring up" blurb, I'd really suggest not just bringing
up a problem, but mentioning a possible real constructive (perhaps
partial) solution too, as part of why that particular person should be
at the KS and why it's worth discussing. We don't want it to be a
"this is a problem I have" kvetching session.

We know part of the agenda already, it was discussed earlier in the
thread. We've had the eternal issue about non-responsive maintainers
and how to try to improve that (whether it's group maintainership or
"fall-through-the-cracks" people or whatever). And I think we've
discussed regression tracking pretty much every year too.

But wouldn't it be good if the KS committee could basically get both a
suggested agenda item and a person selection hint at the same time?

Would there be some convenient way to submit those? We're all email
people, so perhaps just an email with something to easily search for
in the subject line. Just to the list, or who are the actual KS point
men?

On Tue, May 23, 2017 at 12:29 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> I'm happy to try to wrangle interesting and highly technical vendor
> talks.  I believe the current time plan for the maintainer summit is
> half a day (is this correct?), so I propose we do vendor talks in the
> other half of the day.  That way people who aren't interested can take
> the afternoon or morning (depending where people want it in the
> timetable) off to see Prague.

Sounds reasonable by me. Assuming we can get _good_ vendor talks.

              Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 23 May 2017 10:58:36 -0700

> Removed everybody from the cc list except for David, because I still
> want him to give an alternate for the networking subsystem (unless,
> wonder of wonders, you're planning to be in Prague in October,
> David?).

I'm still looking into whether I can be in Prague in October.

My schedule is really tight as we are having netconf/netdev
in early November in Seoul, South Korea.

Unfortunately, I cannot currently recommend anyone seriously as an
alternate to represent networking.  I know that's not the answer you
want to hear, but I'll keep thinking about this.

The last time I left the networking tree in someone else's hands
for even just a few days was about a decade ago and that person's
focus is significantly different these days.

Thanks.

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Linus Torvalds]

On Tue, May 23, 2017 at 8:34 PM, David Miller <davem@davemloft.net> wrote:
>
> I'm still looking into whether I can be in Prague in October.
>
> My schedule is really tight as we are having netconf/netdev
> in early November in Seoul, South Korea.

Ok. Which I assume means that all the other networking people will be
in the same situation.

But maybe there is somebody who is at least close to you from a
workflow and maintainership angle, and where Prague is more convenient
despite netconf/netdev?

Looking at your merges, you seem to merge mostly from Jef Kirsher,
Johannes Berg or Pablo Neira Ayuso.

Although that was from some very rough git scripting that that might
be debatable:

    git rev-list --merges --author=davem --since=12.months  HEAD |
        while read i; do git log -1 --pretty='%cn' $i^2; done |
        sort | uniq -c | sort -n

although looking at that, it really doesn't look like core networking.

Another way to show networking maintainership stats:

    git shortlog -csn --since=12.months net/

and yeah, you clearly do seem to work mostly with patches rather than
submaintainers., backing up that "davem's merge sources aren't very
interesting"

> Unfortunately, I cannot currently recommend anyone seriously as an
> alternate to represent networking.  I know that's not the answer you
> want to hear, but I'll keep thinking about this.
>
> The last time I left the networking tree in someone else's hands
> for even just a few days was about a decade ago and that person's
> focus is significantly different these days.

Heh. Maybe we should have a maintainership discussion about "What if
davem is hit by a bus?" ;)

                    Linus

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 990 bytes --]

On 4/18/2017 2:59 PM, Linus Torvalds wrote:

> I'd like the maintainership summit list to be fairly small. Not even
> 50 people. Maybe 30. A group that can actually sit in a room for half
> a day and talk to each other about the issues they have rather than
> being talked to. And talk literally about *process* issues, not about
> any particular technical issues within whatever subsystem. Bring up
> peeves or wishes for actual process improvements?
> 
> Comments? People who should be involved? Or people who don't have any
> particular issues and want to not be involved?

Hi Linus,

Do we have a final determination as to whether or not this is going to
happen?  I got the impression from this thread that it was "tentative"
and not certain.  If it's going to happen, I should probably get my
travel request in.


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

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

On Wed, 2017-09-20 at 10:45 -0400, Doug Ledford wrote:
> On 4/18/2017 2:59 PM, Linus Torvalds wrote:
> 
> > 
> > I'd like the maintainership summit list to be fairly small. Not
> > even 50 people. Maybe 30. A group that can actually sit in a room
> > for half a day and talk to each other about the issues they have
> > rather than being talked to. And talk literally about *process*
> > issues, not about any particular technical issues within whatever
> > subsystem. Bring up peeves or wishes for actual process
> > improvements?
> > 
> > Comments? People who should be involved? Or people who don't have
> > any particular issues and want to not be involved?
> 
> Hi Linus,
> 
> Do we have a final determination as to whether or not this is going
> to happen?  I got the impression from this thread that it was
> "tentative" and not certain.  If it's going to happen, I should
> probably get my travel request in.

We've collected the sponsor's money and paid for the space, so it's as
certain to happen as any previous kernel summit.  The maintainer's
summit is tacked on to a bigger kernel summit, which is open to all and
also has reserved space in Prague.  You just register for the Open
Source Summit Europe to come to that one:

http://events.linuxfoundation.org/events/linux-kernel-summit/attend/register

James

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --]

On 9/20/2017 11:07 AM, James Bottomley wrote:
> On Wed, 2017-09-20 at 10:45 -0400, Doug Ledford wrote:
>> On 4/18/2017 2:59 PM, Linus Torvalds wrote:
>>
>>>
>>> I'd like the maintainership summit list to be fairly small. Not
>>> even 50 people. Maybe 30. A group that can actually sit in a room
>>> for half a day and talk to each other about the issues they have
>>> rather than being talked to. And talk literally about *process*
>>> issues, not about any particular technical issues within whatever
>>> subsystem. Bring up peeves or wishes for actual process
>>> improvements?
>>>
>>> Comments? People who should be involved? Or people who don't have
>>> any particular issues and want to not be involved?
>>
>> Hi Linus,
>>
>> Do we have a final determination as to whether or not this is going
>> to happen?  I got the impression from this thread that it was
>> "tentative" and not certain.  If it's going to happen, I should
>> probably get my travel request in.
> 
> We've collected the sponsor's money and paid for the space, so it's as
> certain to happen as any previous kernel summit.

I knew the kernel summit was going to happen...

>  The maintainer's
> summit is tacked on to a bigger kernel summit, which is open to all and
> also has reserved space in Prague.

The question is whether or not this is going to happen...

>  You just register for the Open
> Source Summit Europe to come to that one:
> 
> http://events.linuxfoundation.org/events/linux-kernel-summit/attend/register
> 
> James
> 


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley]

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

On Wed, 2017-09-20 at 11:22 -0400, Doug Ledford wrote:
> On 9/20/2017 11:07 AM, James Bottomley wrote:
> > 
> > On Wed, 2017-09-20 at 10:45 -0400, Doug Ledford wrote:
> > > 
> > > On 4/18/2017 2:59 PM, Linus Torvalds wrote:
> > > 
> > > > 
> > > > 
> > > > I'd like the maintainership summit list to be fairly small. Not
> > > > even 50 people. Maybe 30. A group that can actually sit in a
> > > > room for half a day and talk to each other about the issues
> > > > they have rather than being talked to. And talk literally about
> > > > *process* issues, not about any particular technical issues
> > > > within whatever subsystem. Bring up peeves or wishes for actual
> > > > process improvements?
> > > > 
> > > > Comments? People who should be involved? Or people who don't
> > > > have any particular issues and want to not be involved?
> > > 
> > > Hi Linus,
> > > 
> > > Do we have a final determination as to whether or not this is
> > > going to happen?  I got the impression from this thread that it
> > > was "tentative" and not certain.  If it's going to happen, I
> > > should probably get my travel request in.
> > 
> > We've collected the sponsor's money and paid for the space, so it's
> > as certain to happen as any previous kernel summit.
> 
> I knew the kernel summit was going to happen...

I took "this" in your email to refer to Maintainer Summit, so that's
what the above is about.

> >  The maintainer's summit is tacked on to a bigger kernel summit,
> > which is open to all and also has reserved space in Prague.
> 
> The question is whether or not this is going to happen...

Confused by what "this" is here, however: both the kernel summit and
the maintainer summit are happening.  The former merely requires a
OSSE+ELCE pass and the latter an invite.

James

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1698 bytes --]

On 9/20/2017 11:31 AM, James Bottomley wrote:
> On Wed, 2017-09-20 at 11:22 -0400, Doug Ledford wrote:
>> On 9/20/2017 11:07 AM, James Bottomley wrote:

>>>> Do we have a final determination as to whether or not this is
>>>> going to happen?  I got the impression from this thread that it
>>>> was "tentative" and not certain.  If it's going to happen, I
>>>> should probably get my travel request in.
>>>
>>> We've collected the sponsor's money and paid for the space, so it's
>>> as certain to happen as any previous kernel summit.
>>
>> I knew the kernel summit was going to happen...
> 
> I took "this" in your email to refer to Maintainer Summit, so that's
> what the above is about.

Ah, see, while I was on this thread and named by Linus as one of the
subsystems that he sees might benefit from this, I never got an invite
so I didn't know the maintainer summit was happening versus tentative.

>>>  The maintainer's summit is tacked on to a bigger kernel summit,
>>> which is open to all and also has reserved space in Prague.
>>
>> The question is whether or not this is going to happen...
> 
> Confused by what "this" is here,

I was referring to the maintainer's summit.  The kernel summit was a
given, and I thought you were referring to it when you said it was
booked and paid for.

> however: both the kernel summit and
> the maintainer summit are happening.  The former merely requires a
> OSSE+ELCE pass and the latter an invite.

See above as to why I didn't know if it was happening.

-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Theodore Ts'o]

On Wed, Sep 20, 2017 at 11:58:28AM -0400, Doug Ledford wrote:
> Ah, see, while I was on this thread and named by Linus as one of the
> subsystems that he sees might benefit from this, I never got an invite
> so I didn't know the maintainer summit was happening versus tentative.

Linus sent a list of names to the program committee, and with a list a
core people he definitely wanted there, and set of other names, and
asked the program committee to make the final selection, using
criteria that he gave us.

Invites have gone out, and I'll post a draft agenda and confirmed
attendees shortly --- a few people who did receive invites (including
James, cough, cough) haven't RSVP'ed yet.  I'll send nag mails out as
well.

Cheers,

					- Ted

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Morris]

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

On Wed, 20 Sep 2017, James Bottomley wrote:

> We've collected the sponsor's money and paid for the space, so it's as
> certain to happen as any previous kernel summit.  The maintainer's
> summit is tacked on to a bigger kernel summit, which is open to all and
> also has reserved space in Prague.  You just register for the Open
> Source Summit Europe to come to that one:
> 
> http://events.linuxfoundation.org/events/linux-kernel-summit/attend/register

Is there any information available on the format of the open kernel 
summit?  I couldn't find anything on the event web site except a mention 
of a kernel summit track at OSS Europe.


-- 
James Morris
<jmorris@namei.org>

Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Leon Romanovsky]

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

On Wed, Sep 20, 2017 at 06:55:34PM -0400, Theodore Ts'o wrote:
> On Wed, Sep 20, 2017 at 11:58:28AM -0400, Doug Ledford wrote:
> > Ah, see, while I was on this thread and named by Linus as one of the
> > subsystems that he sees might benefit from this, I never got an invite
> > so I didn't know the maintainer summit was happening versus tentative.
>
> Linus sent a list of names to the program committee, and with a list a
> core people he definitely wanted there, and set of other names, and
> asked the program committee to make the final selection, using
> criteria that he gave us.
>
> Invites have gone out, and I'll post a draft agenda and confirmed
> attendees shortly --- a few people who did receive invites (including
> James, cough, cough) haven't RSVP'ed yet.  I'll send nag mails out as
> well.

Is it possible to share this final list publicly?

Thanks

>
> Cheers,
>
> 					- Ted
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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