From: Rudolf Marek <r.marek@assembler.cz>
To: LM Sensors <lm-sensors@lm-sensors.org>
Cc: David Hubbard <david.c.hubbard@gmail.com>,
Hans de Goede <j.w.r.degoede@hhs.nl>,
"Mark M. Hoffman" <mhoffman@lightlink.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] Hardware monitoring subsystem maintainer position is open
Date: Wed, 11 Apr 2007 00:22:06 +0200 [thread overview]
Message-ID: <461C0E0E.5090008@assembler.cz> (raw)
In-Reply-To: <4dfa50520704100846s7c031ab0i9da94a9e993cbbfc@mail.gmail.com>
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
next prev parent reply other threads:[~2007-04-10 22:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070410150227.1bac05b5@hyperion.delvare>
2007-04-10 13:56 ` [lm-sensors] Hardware monitoring subsystem maintainer position is open David Hubbard
2007-04-10 15:40 ` Hans de Goede
2007-04-10 15:46 ` David Hubbard
2007-04-10 22:22 ` Rudolf Marek [this message]
2007-04-10 23:02 ` David Hubbard
2007-04-11 9:24 ` Hans de Goede
2007-04-11 15:08 ` Juerg Haefliger
[not found] ` <461dca480d7ec@wp.pl>
2007-04-12 7:27 ` [lm-sensors] Hardware monitoring subsystem maintainer positionis open Hans de Goede
2007-04-15 2:07 ` Dmitry Torokhov
2007-04-11 9:49 ` Hardware monitoring subsystem maintainer position is open Jean Delvare
2007-04-11 10:06 ` [lm-sensors] " David Hubbard
2007-04-11 14:49 ` Gene Heskett
2007-04-15 15:03 ` [lm-sensors] " Mark M. Hoffman
2007-04-15 17:54 ` Juerg Haefliger
2007-04-15 18:16 ` Rudolf Marek
2007-04-17 8:45 ` Jean Delvare
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=461C0E0E.5090008@assembler.cz \
--to=r.marek@assembler.cz \
--cc=david.c.hubbard@gmail.com \
--cc=j.w.r.degoede@hhs.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=mhoffman@lightlink.com \
/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