Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4922664imu; Sun, 25 Nov 2018 12:57:04 -0800 (PST) X-Google-Smtp-Source: AJdET5ebFYCaJzVMBN+istRinVey7vBKPCiwcYo8r40MUXeTrW2JwNjXBp0l3u0jIITpNb5PEWyC X-Received: by 2002:a62:7652:: with SMTP id r79mr25641378pfc.241.1543179424686; Sun, 25 Nov 2018 12:57:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543179424; cv=none; d=google.com; s=arc-20160816; b=ciNE1X8tLcxpAjFKJ6fG8vfzaM5lbPocPjb70I++oStZbd/Jqpeh39Pu3smyOO12ts AeeF1DVY55bimmqsGRnAvXtsZEHKsKU7r1abjRuBaWeTlsW9lAJHcppTvLm9xKP4v/uD gAoczw7ZgHJnaw4U+s5PnmQMs7shAKxpq7/w1mFOOYZ7NEpqsXTw7JpSDuQNrCOlm70K dM860DEFDSh3lBxtYYt9INzzkCFJ3BildqxtX5vxO39WAvqIqjtpIUgFyBKq3ag11Saa m2V0TxxACaSRohUbnJbcpvATCcu+wyXXScx6/umFvjzeoAcWKeVQwnWXWu9/G2QGBxfK lbfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=bSQj9caCqxRXDmsaARlRivxGvBnJwFh4FjTW2tcYsC0=; b=HVGmPlEZdCC+T7n5OKf0ztjvLWlkJZm2ES7rquj/s9wsHHNqFD+4HhDRqOR36RQaNS 8fROq3g+k9mkQlvLw83VQNqeFSBX07rfhxgV4FeVMaFjsHuGK16h9uP2wF2CHGWc94mx EsK4RfDTzJSJbL7WF4OPMIYTtdBQp6sHo2EQjjvxlXr/25gvqCBCYsl5o6o4ou70bCaS EKnFFMRWN+hVZzdzveHiWyMlBAe9Y78ZGZ9551p4JF8aBT6Xpy7aSfVI4PucOtbCq4qa Bm0JVKtGbdNffbi0k7ZewAF6749PR52USSlXvF8iBh2XD0y4SBHrKloufhQztKNJx+3T 9lPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=d2MUZ9QE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q128si53475352pfc.179.2018.11.25.12.56.49; Sun, 25 Nov 2018 12:57:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=d2MUZ9QE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726049AbeKZHrx (ORCPT + 99 others); Mon, 26 Nov 2018 02:47:53 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:33388 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725902AbeKZHrx (ORCPT ); Mon, 26 Nov 2018 02:47:53 -0500 Received: by mail-oi1-f196.google.com with SMTP id c206so14055096oib.0 for ; Sun, 25 Nov 2018 12:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bSQj9caCqxRXDmsaARlRivxGvBnJwFh4FjTW2tcYsC0=; b=d2MUZ9QEgBJNKpoN1o/fAg4/5DGldNBMqGaWaphDf/DyKFKZzX/c+k0uY/XlR3p8Iy otfFKeiexQyRMKzFONhuVdJ9qQ1iK3mBie5cMyKHCUJTMOsQZVKqa6RC3ZCtyNXJ+mNH BxE1MUpD9yUwUEsgfPLCnizWOVEM1uWredKI/OYxGvTVbC+01f/ZQLOkLt1HdAc9cX9e tKwY85TZxHTkzyjj62lM4gbj+RRcPO1L+a5STucIynWVEWVk8NkWwHTqeGB79Wka76Oh 3ppwLr1xA5zWdORWi4c7Zlflcbs0FNnIcKhVbZUzbZmHh+zB6Jk63VyRUmcf2vIFEDBE xCkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bSQj9caCqxRXDmsaARlRivxGvBnJwFh4FjTW2tcYsC0=; b=nsF9Gfmw6RcyQgnqzgfsTqSJQMveMsUkOtEMuYuqkunlmJHScwYt/Ff09sD1qZLbFj Fh0kuYgXErOo8XmL97qOyeTqCoVYEaI7ig9aL4TCF3/Z7ftmW4G776KN3v0A9U400h8z bousKOBeatbbW4MHlH5EHarF3eA03mFBqLTOjKy+I9UJ3bzsJIQbpsXqa2xw2Ung7MPL S/OYXVqtucPs/uVuqR77n+Xz9ydQK9swIGvK9YsYMwcQlW1IsQ8I0JY6vNDh0KRqOXyB S7pz3dL+4fet+YN7NGf5oepoRtyrVZuGTbtJesrlKteGACGQUnIjWCp5wjZzQb8Bpfgy ix0Q== X-Gm-Message-State: AGRZ1gKRwdbZejQk8iqMp+loFDK9GNCKSdbxpBgWSx9rfnNBVFUyrgX4 QG0wi6dFXQYgBQI9uE9bSw4cc9+DYGCsKlCRCOAVkg== X-Received: by 2002:aca:2dc8:: with SMTP id t191mr12933109oit.235.1543179356729; Sun, 25 Nov 2018 12:55:56 -0800 (PST) MIME-Version: 1.0 References: <154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com> <20181125105754.GB25471@amd> In-Reply-To: <20181125105754.GB25471@amd> From: Dan Williams Date: Sun, 25 Nov 2018 12:55:45 -0800 Message-ID: Subject: Re: [RFC PATCH 0/3] Maintainer Handbook: Subsystem Profile To: Pavel Machek Cc: Linux Kernel Mailing List , Mauro Carvalho Chehab , Dave Jiang , Daniel Vetter , Linus Torvalds , Dmitry Vyukov , Vishal L Verma , Jonathan Corbet , Thomas Gleixner , zwisler@kernel.org, Joe Perches , "Tobin C. Harding" , "Martin K. Petersen" , Greg KH , stfrench@microsoft.com, Olof Johansson , linux-nvdimm , ksummit Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 25, 2018 at 2:58 AM Pavel Machek wrote: > > On Wed 2018-11-14 20:53:13, Dan Williams wrote: > > At a recently concluded session at the Linux Plumbers Conference I > > proposed a "Subsystem Profile" as a document that a maintainer can > > provide to set contributor expectations and provide fodder for a > > discussion between maintainers about the merits of different maintainer > > policies. > > > > For those that did not attend, the goal of the Subsystem Profile, and the > > Maintainer Handbook more generally, is to provide a desk reference for > > maintainers both new and experienced. The session introduction was: > > > > The first rule of kernel maintenance is that there are no hard and > > fast rules. That state of affairs is both a blessing and a curse. It > > has served the community well to be adaptable to the different > > people and different problem spaces that inhabit the kernel > > community. However, that variability also leads to inconsistent > > experiences for contributors, little to no guidance for new > > contributors, and unnecessary stress on current maintainers. There > > are quite a few of people who have been around long enough to make > > enough mistakes that they have gained some hard earned proficiency. > > However if the kernel community expects to keep growing it needs to > > be able both scale the maintainers it has and ramp new ones without > > necessarily let them make a decades worth of mistakes to learn the > > ropes. > > > > To be clear, the proposed document does not impose or suggest new > > rules. Instead it provides an outlet to document the unwritten rules > > and policies in effect for each subsystem, and that each subsystem > > might decide differently for whatever reason. > > Sounds like a new rules to me :-(, making submitting simple patches > harder. I'm missing how documenting how a subsystem generally handles patches makes submitting simple patches harder? > It would be good if the rules were similar / same accross the > subsystems, documenting "it is okay to be different" is not really helpful. It is not documenting "it is okay to be different", it is acknowledging that processes are already different. The goals are to allow comparing notes across subsystems with the hope of some convergence down the road, provide a template for new maintainers to copy rather than reinvent, and give submitters a resource to discover subsystem local policy.