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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2015-07-16 at 09:41 -0600, Jonathan Corbet wrote:
> On Thu, 16 Jul 2015 08:04:30 -0700
> Tim Bird <tim.bird@sonymobile.com> wrote:
> 
> > On 07/16/2015 06:47 AM, Steven Rostedt wrote:
> > > One of the issues with newcomers coming to development of the Linux
> > > kernel, is that every maintainer is different. We should be trying
> > > harder to let people know what we prefer. Every maintainer expects
> > > something different, but it's up to the maintainer to explicitly let
> > > others know what they want. You can't expect everyone to read your mind.  
> > 
> > I agree with this completely.  When you switch systems (which I've done
> > something like 5 times in the last 2 years), you are essentially a newbie
> > in that new system.
> > 
> > How about putting some notes in the MAINTAINER file for things like
> > this, that some get_maintainer.pl option could show? 
> > We could use a I: prefix, for "Instructions:"  (only because 'N:'
> > is already used.)
> 
> So somebody has to play the devil's advocate and ask this question...
> Are we really better off documenting the fact that what looks like a
> single project is actually a collection of a hundred or so idiosyncratic
> fiefdoms with their own contact protocols, coding styles, beer
> preferences, and more? Or perhaps we might think about gravitating toward
> a more uniform set of conventions?  Preferably the ones I use? :)
> 
> Seriously, this area is a minefield for new developers; it can be
> discouraging to put together your first patch, carefully follow
> everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
> HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
> with the correct command-line options, and follow all the suggestions
> provided by reddit, Phoronix and 4chan, only to be told that the patch
> came in during the wrong phase of the moon and they really should have
> known better.

If I play Devil's advocate to the existing Devil's advocate, does that
make me one of the good guys ...?

Before we all beat ourselves up for being a complete cesspool of process
and timing obsessed freaks, perhaps people would like to reflect on
this:

http://www.alexconrad.org/2014/04/the-painful-process-of-submitting-your.html

Sometimes adding layers of carefully documented process and automated
abstractions actually ends up giving you precisely what you were trying
to avoid.

Seriously, what is the actual problem?  Who bites the heads off newbies
for sport?  I ask because the first patch submission is usually treated
with helpfulness and tolerance, at least where I've been on the cc list.
The wrong phase of the merge cycle can be a bugger, particularly when
most people's attention is elsewhere, but it's not like it's a huge
deterrent.  We all have developers who'd rather spit rats than submit a
patch to $opensourceprojecttheyfoundabugin but then, it's sometimes
because the reply might contradict their own mythology (or question
their reputation).  Before we embark on a huge does of hair shirt and a
lavish process dump, what is the problem we're trying to solve?

James