linux-kernel - Re: [lm-sensors] Hardware monitoring subsystem maintainer position is open

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Apr 2007 00:22:06 +0200
From:	Rudolf Marek <r.marek@...embler.cz>
To:	LM Sensors <lm-sensors@...sensors.org>
CC:	David Hubbard <david.c.hubbard@...il.com>,
	Hans de Goede <j.w.r.degoede@....nl>,
	"Mark M. Hoffman" <mhoffman@...htlink.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [lm-sensors] Hardware monitoring subsystem maintainer position
 is open

Hello all,

First I would like to thank Jean for his great work even if could be seen as 
"slow". He did the perfect job, allowing only just perfect code to enter the trees.

> I haven't seen anything from Rudolf Marek, but he is definitely
> qualified if he wants to step up. I'm personally hoping Jean changes
> his mind.

Well I'm afraid Jean thought about this twice and I think his decision cannot be 
changed easily. Personally I think that change of one person to another won't 
change much. Problem we are facing is long delay between the post of the driver 
to driver merge.

Review of one complex driver takes hours and hours. If the fixes could be split 
into critical and non-critical parts driver could be accepted earlier and marked 
as EXPERIMENTAL in very new (for hwmon ;) meaning of the word. I mean Jean did 
great job and spotted all troubles during the review, so there were nearly none 
of bug fixes for already merged drivers.

Maybe we could try following:

1) person post the driver
2) quick review could be done critical fixes only, driver goes to -mm
3) review that goes deeper - check for interface conformity and all the stuff 
which could break - fixes for non-critical stuff
4) after this driver goes to Linus tree at the very beginning for the merge 
cycle marked as EXPERIMENTAL
5) if the person agrees to be in MAINTAINER final review may be done and 
EXPERIMENTAL could be removed. (This is step which might involve all steps to 
make the driver really perfect ;)

Well this is just an idea. Neither it does solve the maintainer problem, nor it 
is perfect solution.

As for the proposal of David. I joined the list in 2004 with my very own driver 
and learned a lot from Jean and others and on my own ;) During last year??? I 
was doing some kind of "review preprocessor" to help Jean with that. I still 
have feeling Jean is simply better. Second reason why I hesitating to say "I 
will take it" is time. This would cost a lot of time, but unfortunately my free 
time is very tight. I'm doing PhD and working for a embedded stuff company 
(SYSGO). Moreover I would like to meet some nice girl for a life, which is quite 
difficult and also quite time consumptive ;).

Personally better would be go with Jean and some kind of scheme noted above, 
which would solve our "takes too long problem" and preserve the high quality of 
drivers. This would mean some co-maintainers to Jean, rather than to live 
without Jean at all.

Thanks,
Rudolf

-
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/