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

[Alexandre Belloni <alexandre.belloni@free-electrons.com>]

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

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

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