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

[Sarah A Sharp]

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.

Sarah Sharp