[Ksummit-discuss] "Maintainer summit" invitation discussion

Guenter Roeck linux at roeck-us.net
Tue Apr 25 16:38:20 UTC 2017


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


More information about the Ksummit-discuss mailing list