linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: "Hans J. Koch" <hjk@hansjkoch.de>
Cc: Joe Perches <joe@perches.com>, Michal Simek <monstr@monstr.eu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: [lm-sensors] [PATCH] MAINTAINERS: Remove Hans J. Koch entries
Date: Fri, 21 Jun 2013 09:47:38 +0200	[thread overview]
Message-ID: <20130621094738.7216c29d@endymion.delvare> (raw)
In-Reply-To: <20130621025031.GG4775@local>

Hi Hans and all,

On Fri, 21 Jun 2013 04:50:31 +0200, Hans J. Koch wrote:
> On Thu, Jun 20, 2013 at 09:20:27AM -0700, Joe Perches wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 69fea4f..dc9d04a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5253,9 +5253,8 @@ F:	Documentation/hwmon/max16065
> >  F:	drivers/hwmon/max16065.c
> >  
> >  MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
> > -M:	"Hans J. Koch" <hjk@hansjkoch.de>
> >  L:	lm-sensors@lm-sensors.org
> > -S:	Maintained
> > +S:	Orphan
> >  F:	Documentation/hwmon/max6650
> >  F:	drivers/hwmon/max6650.c
> 
> ACK to that one. It was never my idea to have a MAINTAINERS entry for that.
> Jean Delvare suggested it, so it came in. The MAX6650 was in a project I was
> working on 6 years ago, and I wrote the driver at that time. Meanwhile, I
> don't even have hardware with a MAX6650 anymore.

Back then I was maintaining the hwmon subsystem all by myself and had
way more than I could handle on my plate. Contributors kept complaining
that I was too slow reviewing new drivers and having them add
themselves to MAINTAINERS was my way to help them understand that Linux
wasn't only about adding new driver, and that every piece of code added
to the kernel had to be maintained by someone for the years to come.
And that someone was rather them than me.

That being said, I agree it only makes sense for as long as the
original contributor (or anyone else wanting to step in) has the
hardware, interest and knowledge for the driver in question. After
several years it makes sense to drop these individual driver entries if
these conditions are no longer met.

> Does each little driver really need a MAINTAINERS entry? In my opinion, it
> should only be there if it is clear that it's not just a short project work.

The number of drivers in all kernel subsystems keeps growing, and hwmon
is no exception. The number of subsystem maintainers, OTOH, is not
growing, it's typically one or two persons doing all the work. This is
why I value individual driver maintainers, as they help make it all
scale. If existing drivers each have their own maintainer, subsystem
maintainers can focus on subsystem-wide cleanups and reviewing new
drivers.

But of course MAINTAINERS must reflect the reality and not my own
fantasy world where every single driver would have a dedicated
maintainer. If anyone listed as a driver maintainer in MAINTAINERS is
not actually going to do the job for whatever reason, then the entry
should be removed.

-- 
Jean Delvare

  parent reply	other threads:[~2013-06-21  7:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-23 14:01 [RFC PATCH 1/2] uio: Use Use of_match_ptr() macro in uio_pdrv_genirq.c Michal Simek
2013-05-23 14:01 ` [RFC PATCH 2/2] uio: Add two platform uio drivers to one Michal Simek
2013-05-29 11:28   ` Michal Simek
2013-06-03 12:34     ` Michal Simek
2013-06-03 21:05       ` Greg Kroah-Hartman
2013-06-12  5:43         ` Michal Simek
2013-06-20 16:01         ` Pavel Machek
2013-06-20 16:20           ` [PATCH] MAINTAINERS: Remove Hans J. Koch entries Joe Perches
2013-06-20 16:30             ` [lm-sensors] " Guenter Roeck
2013-06-20 17:09               ` Joe Perches
2013-06-21  2:50             ` Hans J. Koch
2013-06-21  3:08               ` Joe Perches
2013-06-21  7:47               ` Jean Delvare [this message]
2013-06-21  9:15               ` Michal Simek
2013-06-20 17:11           ` [RFC PATCH 2/2] uio: Add two platform uio drivers to one Michal Simek
2013-06-20 23:13             ` Pavel Machek
2013-06-21  9:06               ` Michal Simek
2013-06-10  8:59   ` Michal Simek

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=20130621094738.7216c29d@endymion.delvare \
    --to=khali@linux-fr.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hjk@hansjkoch.de \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=monstr@monstr.eu \
    --cc=pavel@ucw.cz \
    /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;
as well as URLs for NNTP newsgroup(s).