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

[Tim Bird <tim.bird@sonymobile.com>]

On 07/16/2015 08:41 AM, 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.
Indeed.

> Not sure what the real answer is, but something tells me that adding a
> new domain-specific language to MAINTAINERS isn't quite it :)
Not to rain on my own idea, but I strenuously agree.  I think one of
the reasons the SubmittingPatches files is not exhaustive is that
there are too many differences between maintainers for some things,
and some things change, even for a single maintainer, given the
type of patch and current maintainer circumstances.  Adding
to MAINTAINERS doesn't address this last variability at all.

We've been loathe to try to enforce consistency of process for
maintainers, thinking it would harm maintainer productivity (and
it well might).  But it makes automation hard, and you do end
up with newbies facing these daunting 110-step processes, which
still omit important steps, and might be contradictory for 
cross-system submissions.
 -- Tim