From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 22 Oct 2015 22:01:10 +0200 From: Alexandre Belloni To: Theodore Ts'o Message-ID: <20151022200110.GG10000@piout.net> References: <20151020220328.GA21941@thunk.org> <20151021145626.GD2165@thunk.org> <5627AD56.7050500@roeck-us.net> <20151021160907.GM32054@sirena.org.uk> <5627BF30.4080703@roeck-us.net> <20151022152502.GA28761@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151022152502.GA28761@thunk.org> Cc: ksummit-discuss@lists.linux-foundation.org Subject: Re: [Ksummit-discuss] Kernel Summit Agenda -- 2nd draft List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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