lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 21 Jun 2013 09:47:38 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	"Hans J. Koch" <hjk@...sjkoch.de>
Cc:	Joe Perches <joe@...ches.com>, Michal Simek <monstr@...str.eu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org,
	Pavel Machek <pavel@....cz>
Subject: Re: [lm-sensors] [PATCH] MAINTAINERS: Remove Hans J. Koch entries

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@...sjkoch.de>
> >  L:	lm-sensors@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ