Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

[Greg KH <greg@kroah.com>]

On Mon, Jul 20, 2015 at 10:27:39AM +0200, Julia Lawall wrote:
> 
> 
> On Mon, 20 Jul 2015, James Bottomley wrote:
> 
> > On Mon, 2015-07-20 at 00:19 +0200, Jiri Kosina wrote:
> > > On Fri, 17 Jul 2015, Steven Rostedt wrote:
> > >
> > > [ ... snip ... ]
> > > > But that was an exception because the code submitted was really worth
> > > > while
> > >
> > > This really made me wonder. Maybe we should really focus on why such
> > > ocasions need to be pointed out as exceptions.
> > >
> > > Is it that Linux kernel development got hyped so much that everyone wants
> > > to have that bullet in his CV, no matter how stupid the submitted patch
> > > would be?
> > >
> > > If so, what should we do to change it?
> > >
> > > I.e. I might propose a a slightly controversial topic, going a bit the
> > > other direction than the whole "motivating newcomers" discussion: how to
> > > get rid of useless submissions that are slowing maintainers down?
> >
> > I second.  I think we concentrate too much on contribution and not
> > enough on useful contribution.
> >
> > > Should we stop publishing all the statistics? I believe there is no
> > > question that those are one of the primary drivers of useless submissions.
> > > Once maintainers get DoSed by submissions of wrong and/or useless patches
> > > that eat non-negligible amount of their time, we're in trouble.
> >
> > I'm not sure it's just the stats.  We also have to be careful about
> > negative perceptions, so I don't think we want to go around highlighting
> > bad patches.  There are a couple of patch sets that are draining review
> > talent from my point of view: the mechanical one file at a time fixing
> > X.  I think we need someone to be the gatekeeper and review and apply
> > the script in one go.  And perhaps we should call the other "small
> > patches which don't fix bugs" ... I'm less sure what to do about these.
> 
> If there really is a problem that some maintainer is getting inundated
> with patches addressing unimportant cosmetic issues, could it be a good
> idea to:
> 
> * Fix the code and get it over with,
> * Drop the code from the kernel, if no one uses it, or
> * Put a comment in the file saying that the file is no longer being
> actively developed and only bug fixes will be accepted.

I agree with this.  If your subsystem is constantly getting hit with
coding style cleanups that you don't want (i.e. SCSI), put something in
the top of the file that says "don't clean up the style".

Of course it will be ignored (like pci_ids.h), but then you can write a
simple script that just rejects such patches with a "Sorry, but please
read the top of the file" rejection notice.

There, annoying patches taken care of.

greg k-h