[Ksummit-discuss] [TOPIC] Guidance for subsystem maintainers

[Laurent Pinchart]

Hi Sarah,

On Tuesday 13 May 2014 07:57:16 Sarah A Sharp wrote:
> On Tue, May 13, 2014 at 7:31 AM, Jiri Kosina <jkosina at suse.cz> wrote:
> > On Tue, 13 May 2014, Takashi Iwai wrote:
> >> While posting to different subsystem areas, I noticed various ways of
> >> responses and communications.  Some picks up quick, some urges more
> >> reviews, sometimes a patch gets merged silently after months later,
> >> etc.  Although the variety is one strength of OSS development, it made
> >> me also wonder whether we need some baseline guidance for subsystem
> >> maintenance in order to give a better appeal to casual developers.
> >> 
> >> Is such a thing too much burden to maintainers?  Or, is it just a
> >> bikeshedding?
> > 
> > I am afraid that any attempt to force any working style on maintainers is
> > pre-destined to fail.
> > 
> > As an example, there are folks who love patchwork and others wouldn't dare
> > to touch it with a 10m pole.
> > 
> > Even such a "core" thing as git is explicitly claimed optional by Linus.
> > 
> > Is there perhaps anything more concrete you had on mind?
> 
> Technical workflows will always be different.  I believe what Takashi
> is talking about is a social problem, not a technical problem.  Each
> maintainer needs some level of confidence in the patch, and thus some
> maintainers will wait a while before merging a patch, or wait for
> additional reviewers to ack it.  And sometimes that means the patch
> falls through the cracks.  Others will just throw the patch at their
> -next branch, do some quick testing, and catch bugs in the next -rc
> cycle.
> 
> Patch testing and review is a social problem, and trying to mandate a
> workflow or even a set of technical tools will not help solve the
> social problem of patches getting dropped or ignored.

Wouldn't it help if we could write down whatever rules that each subsystem 
maintainer found best ? For instance some maintainers expect to be CC'ed on 
patch submission, other prefer not to be CC'ed. When sending a patch to a new 
subsystem developers currently have no easy way to find this kind of 
information. We can of course expect them to do their homework and step in the 
subsystem to find out what's happening, but when modifying drivers across the 
whole kernel to support a new system that's a pretty large effort.

-- 
Regards,

Laurent Pinchart