From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7CA1E8B4 for ; Thu, 16 Jul 2015 15:53:03 +0000 (UTC) Received: from seldrel01.sonyericsson.com (seldrel01.sonyericsson.com [37.139.156.2]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8412EEB for ; Thu, 16 Jul 2015 15:53:02 +0000 (UTC) Message-ID: <55A7D358.7070203@sonymobile.com> Date: Thu, 16 Jul 2015 08:52:56 -0700 From: Tim Bird MIME-Version: 1.0 To: Jonathan Corbet References: <20150708114011.3a1f1861@noble> <2879113.fraeuJIr2M@avalon> <20150709193718.GD9169@vmdeb7> <20150710143641.GW4341@mwanda> <20150710160714.GL111846@vmdeb7> <20150710222351.GA28632@kroah.com> <20150711000034.GU111846@vmdeb7> <20150711001348.GA30675@kroah.com> <20150711055441.GA6316@sudip-PC> <20150715212043.775be5d2@gandalf.local.home> <20150716132551.GH4039@sirena.org.uk> <20150716094720.2bf9f5ac@gandalf.local.home> <55A7C7FE.6000604@sonymobile.com> <20150716094125.16cdda73@lwn.net> In-Reply-To: <20150716094125.16cdda73@lwn.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Cc: Dan Carpenter , "ksummit-discuss@lists.linuxfoundation.org" , Jason Cooper Subject: Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 07/16/2015 08:41 AM, Jonathan Corbet wrote: > On Thu, 16 Jul 2015 08:04:30 -0700 > Tim Bird 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