mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
Cc: corbet@lwn.net, linux@leemhuis.info,
	konstantin@linuxfoundation.org, krzysztof.kozlowski@linaro.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] get_maintainer: Describe supporters and maintainers as required email recipients
Date: Wed, 28 Sep 2022 23:29:10 -0400	[thread overview]
Message-ID: <YzURBpkWU1hHM7rN@mit.edu> (raw)
In-Reply-To: <20220929002500.283481-2-bryan.odonoghue@linaro.org>

On Thu, Sep 29, 2022 at 01:24:59AM +0100, Bryan O'Donoghue wrote:
> The output of get_maintainer.pl doesn't make clear that a supporter is a
> type of maintainer who should be mailed when generating a patch.
> 
> In various places in the documentation we make reference to the necessity
> to remember to include the appropriate maintainers when sending your patch
> but, we confusingly don't call out supporters as maintainers in our
> automation utility.
> 
> Fix that up now by having get_maintainers.pl print 'maintainer[volunteer]'
> or 'maintainer[supporter]'.

I really don't think this is correct.  Or at least, I don't think it's
consistent with how we've historically understood the S: term in the
MAINTAINERS file.  First of all, the Status field is a property of the
*subsystem*, not of the *maintainer*.

	S: *Status*, one of the following:
	   Supported:	Someone is actually paid to look after this.
	   Maintained:	Someone actually looks after it.
	   Odd Fixes:	It has a maintainer but they don't have time to do
			much other than throw the odd patch in. See below..
	   Orphan:	No current maintainer [but maybe you could take the
			role as you write your new code].
	   Obsolete:	Old code. Something tagged obsolete generally means
			it has been replaced by a better system and you
			should be using that.

There are also plenty of projects which are marked "Maintained" where
one or more the maintainers are paid to support that subsystem (while
others might be volunteers).

So to have get_maintainers.pl print that someone is a
maintainer[volunteer] versus maintainer[supporter] is going to be
highly misleading.  What if one of the maintainers is paid by some
larger company (say, Google or Facebook or Red Hat), while the other
maintainer is a hobbists?  And what for the maintainer who is paid by
a large company, there are multiple levels of "supported".  They might
be allowed to spend up to 50% of the paid time working on upstream
work.  Does that make them a "supported" or a "volunteer"?  And how
should the subsystem's S: be marked?

I understand that get_maintinaer.pl has had this get_maintainer_role
function for a long time; it's not been introduced by this patch.  But
I'd suggest that we not try to make a distinction between a subsystem
which is "Supported" versus "Maintained", and certainly we should not
be treating an attribute of the subsystem as being attached to all of
the entities listed under M:.  That is really a category error, IMHO.

    	     	    	       	       - Ted

  reply	other threads:[~2022-09-29  3:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29  0:24 [PATCH v2 0/2] Expand get_maintainer to be explicit about supporters Bryan O'Donoghue
2022-09-29  0:24 ` [PATCH v2 1/2] get_maintainer: Describe supporters and maintainers as required email recipients Bryan O'Donoghue
2022-09-29  3:29   ` Theodore Ts'o [this message]
2022-09-29  7:58     ` Thorsten Leemhuis
2022-09-29  0:25 ` [PATCH v2 2/2] Documentation/process: Add text to indicate supporters should be mailed Bryan O'Donoghue
2022-09-29  7:29   ` Krzysztof Kozlowski
2022-09-29 10:33     ` Bryan O'Donoghue
2022-09-29 11:15       ` Krzysztof Kozlowski
2022-09-29 10:52     ` Bryan O'Donoghue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YzURBpkWU1hHM7rN@mit.edu \
    --to=tytso@mit.edu \
    --cc=bryan.odonoghue@linaro.org \
    --cc=corbet@lwn.net \
    --cc=konstantin@linuxfoundation.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®