[lm-sensors] Hardware monitoring subsystem maintainer position is

[lm-sensors] Hardware monitoring subsystem maintainer position is

[Jean Delvare]

Hi all,

I am resigning from my role as hardware monitoring subsystem
(drivers/hwmon) maintainer. This is too much work for me, I do not have
the necessary bandwidth to review all the incoming patches, in
particular new drivers, in a timely manner. Patch authors have been
complaining about this repeatedly. This is no fun for them, and even
less for me, so I'd rather let someone else with more spare time take
care of it. If there are volunteers, this is the right time to speak up.

I will still be maintaining the individual hardware monitoring drivers
I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
as well as the I2C subsystem. No change here.

I will continue to feed -mm with pending hwmon patches until 2.6.21
final is released, then I'll send everything I have to Linus for
2.6.22-rc1, the last of which will be:

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 MAINTAINERS |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

--- linux-2.6.21-rc6.orig/MAINTAINERS	2007-04-10 13:49:09.000000000 +0200
+++ linux-2.6.21-rc6/MAINTAINERS	2007-04-10 14:28:31.000000000 +0200
@@ -1467,12 +1467,9 @@ W:	http://gigaset307x.sourceforge.net/
 S:	Maintained
 
 HARDWARE MONITORING
-P:	Jean Delvare
-M:	khali@linux-fr.org
 L:	lm-sensors@lm-sensors.org
 W:	http://www.lm-sensors.org/
-T:	quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-hwmon/
-S:	Maintained
+S:	Orphan
 
 HARDWARE RANDOM NUMBER GENERATOR CORE
 P:	Michael Buesch

Then I'll probably keep an eye on hwmon in Linus' tree until 2.6.22
final is released, and after that I'm done with it.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[David Hubbard]

Jean,

I for one will greatly miss your knowledge and helpful hints when I
work on hardware monitoring drivers. I hope you find success in all
the things you do!

I understand the difficult position you're in, and if there's any way
I could convince you to stay, I would. Maybe you would be willing to
answer a few low-bandwidth questions from time to time? Or jump on to
#linux-sensors every once in a while?

Either way, thanks for everything!

Cheers,
David

On 4/10/07, Jean Delvare <khali@linux-fr.org> wrote:
> Hi all,
>
> I am resigning from my role as hardware monitoring subsystem
> (drivers/hwmon) maintainer. This is too much work for me, I do not have
> the necessary bandwidth to review all the incoming patches, in
> particular new drivers, in a timely manner. Patch authors have been
> complaining about this repeatedly. This is no fun for them, and even
> less for me, so I'd rather let someone else with more spare time take
> care of it. If there are volunteers, this is the right time to speak up.
>
> I will still be maintaining the individual hardware monitoring drivers
> I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> as well as the I2C subsystem. No change here.
>
> I will continue to feed -mm with pending hwmon patches until 2.6.21
> final is released, then I'll send everything I have to Linus for
> 2.6.22-rc1, the last of which will be:
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> ---
>  MAINTAINERS |    5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- linux-2.6.21-rc6.orig/MAINTAINERS   2007-04-10 13:49:09.000000000 +0200
> +++ linux-2.6.21-rc6/MAINTAINERS        2007-04-10 14:28:31.000000000 +0200
> @@ -1467,12 +1467,9 @@ W:       http://gigaset307x.sourceforge.net/
>  S:     Maintained
>
>  HARDWARE MONITORING
> -P:     Jean Delvare
> -M:     khali@linux-fr.org
>  L:     lm-sensors@lm-sensors.org
>  W:     http://www.lm-sensors.org/
> -T:     quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-hwmon/
> -S:     Maintained
> +S:     Orphan
>
>  HARDWARE RANDOM NUMBER GENERATOR CORE
>  P:     Michael Buesch
>
> Then I'll probably keep an eye on hwmon in Linus' tree until 2.6.22
> final is released, and after that I'm done with it.
>
> --
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[David Hubbard]

Jean,

I for one will greatly miss your knowledge and helpful hints when I
work on hardware monitoring drivers. I hope you find success in all
the things you do!

I understand the difficult position you're in, and if there's any way
I could convince you to stay, I would. Maybe you would be willing to
answer a few low-bandwidth questions from time to time? Or jump on to
#linux-sensors every once in a while?

Either way, thanks for everything!

Cheers,
David

On 4/10/07, Jean Delvare <khali@linux-fr.org> wrote:
> Hi all,
>
> I am resigning from my role as hardware monitoring subsystem
> (drivers/hwmon) maintainer. This is too much work for me, I do not have
> the necessary bandwidth to review all the incoming patches, in
> particular new drivers, in a timely manner. Patch authors have been
> complaining about this repeatedly. This is no fun for them, and even
> less for me, so I'd rather let someone else with more spare time take
> care of it. If there are volunteers, this is the right time to speak up.
>
> I will still be maintaining the individual hardware monitoring drivers
> I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> as well as the I2C subsystem. No change here.
>
> I will continue to feed -mm with pending hwmon patches until 2.6.21
> final is released, then I'll send everything I have to Linus for
> 2.6.22-rc1, the last of which will be:
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> ---
>  MAINTAINERS |    5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- linux-2.6.21-rc6.orig/MAINTAINERS   2007-04-10 13:49:09.000000000 +0200
> +++ linux-2.6.21-rc6/MAINTAINERS        2007-04-10 14:28:31.000000000 +0200
> @@ -1467,12 +1467,9 @@ W:       http://gigaset307x.sourceforge.net/
>  S:     Maintained
>
>  HARDWARE MONITORING
> -P:     Jean Delvare
> -M:     khali@linux-fr.org
>  L:     lm-sensors@lm-sensors.org
>  W:     http://www.lm-sensors.org/
> -T:     quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-hwmon/
> -S:     Maintained
> +S:     Orphan
>
>  HARDWARE RANDOM NUMBER GENERATOR CORE
>  P:     Michael Buesch
>
> Then I'll probably keep an eye on hwmon in Linus' tree until 2.6.22
> final is released, and after that I'm done with it.
>
> --
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

Jean Delvare wrote:
> Hi all,
> 
> I am resigning from my role as hardware monitoring subsystem
> (drivers/hwmon) maintainer. This is too much work for me, I do not have
> the necessary bandwidth to review all the incoming patches, in
> particular new drivers, in a timely manner. Patch authors have been
> complaining about this repeatedly. This is no fun for them, and even
> less for me, so I'd rather let someone else with more spare time take
> care of it. If there are volunteers, this is the right time to speak up.
> 

I'm sorry to hear this and I can't help but think that my, erm, rant* yesterday 
is somehow involved in you making this decision. This was in no way my 
intention. My intention was to try and make you change how you handle these 
things, my intention was to make you less of a perfectionist and to distribute 
the work more, you cannot do everything yourself. I think that if you could 
change that you would be able to cope with the load better.

I think you're experience / knowledge when it comes to hwmon stuff is very 
valuable and if you leave / quit doing hwmon stuff this would be a big loose. I 
also believe that with a looser management style, you could seriously reduce 
your workload coming from being the hwmon maintainer and at the same time get a 
better / faster flow of patches.

But alas, I'm afraid I cannot change your mind, so that brings us to the 
question who will pickup the task. I've considered volunteering myself, but I'm 
to inexperienced when it comes to kernel stuff and lm-sensors for me is kinda a 
side project. I sink most of my spare time into Fedora where I maintain circa 
120 packages, which really means I have little time left for lm-sensors (to be 
clear the average package maintainer maintains between 30 - 50 packages).

However I do hereby promise to help the new "Jean" in anyway I can, and 
although not many know me very well here I think I can safely say I can help in 
many ways. I'm a (very) experienced c-programmer specialised in lowlevel code, 
embedded (linux) systems, etc. and I have a bachelor in electronics. So 
who-ever becomes the new "Jean" don't hesitate to ask for help, the worst thing 
that can happen is that I say no :)

Jean, thanks for all your hard work the past years!

Regards,

Hans

* for those not on the lmsensors list I am one of the complaining patch authors

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Hans de Goede]

Jean Delvare wrote:
> Hi all,
> 
> I am resigning from my role as hardware monitoring subsystem
> (drivers/hwmon) maintainer. This is too much work for me, I do not have
> the necessary bandwidth to review all the incoming patches, in
> particular new drivers, in a timely manner. Patch authors have been
> complaining about this repeatedly. This is no fun for them, and even
> less for me, so I'd rather let someone else with more spare time take
> care of it. If there are volunteers, this is the right time to speak up.
> 

I'm sorry to hear this and I can't help but think that my, erm, rant* yesterday 
is somehow involved in you making this decision. This was in no way my 
intention. My intention was to try and make you change how you handle these 
things, my intention was to make you less of a perfectionist and to distribute 
the work more, you cannot do everything yourself. I think that if you could 
change that you would be able to cope with the load better.

I think you're experience / knowledge when it comes to hwmon stuff is very 
valuable and if you leave / quit doing hwmon stuff this would be a big loose. I 
also believe that with a looser management style, you could seriously reduce 
your workload coming from being the hwmon maintainer and at the same time get a 
better / faster flow of patches.

But alas, I'm afraid I cannot change your mind, so that brings us to the 
question who will pickup the task. I've considered volunteering myself, but I'm 
to inexperienced when it comes to kernel stuff and lm-sensors for me is kinda a 
side project. I sink most of my spare time into Fedora where I maintain circa 
120 packages, which really means I have little time left for lm-sensors (to be 
clear the average package maintainer maintains between 30 - 50 packages).

However I do hereby promise to help the new "Jean" in anyway I can, and 
although not many know me very well here I think I can safely say I can help in 
many ways. I'm a (very) experienced c-programmer specialised in lowlevel code, 
embedded (linux) systems, etc. and I have a bachelor in electronics. So 
who-ever becomes the new "Jean" don't hesitate to ask for help, the worst thing 
that can happen is that I say no :)

Jean, thanks for all your hard work the past years!

Regards,

Hans

* for those not on the lmsensors list I am one of the complaining patch authors


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[David Hubbard]

Hi Hans,

On 4/10/07, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Jean Delvare wrote:
> > Hi all,
> >
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
>
> But alas, I'm afraid I cannot change your mind, so that brings us to the
> question who will pickup the task. I've considered volunteering myself, but I'm
> to inexperienced when it comes to kernel stuff and lm-sensors for me is kinda a
> side project. I sink most of my spare time into Fedora where I maintain circa
> 120 packages, which really means I have little time left for lm-sensors (to be
> clear the average package maintainer maintains between 30 - 50 packages).

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.

David

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[David Hubbard]

Hi Hans,

On 4/10/07, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Jean Delvare wrote:
> > Hi all,
> >
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
>
> But alas, I'm afraid I cannot change your mind, so that brings us to the
> question who will pickup the task. I've considered volunteering myself, but I'm
> to inexperienced when it comes to kernel stuff and lm-sensors for me is kinda a
> side project. I sink most of my spare time into Fedora where I maintain circa
> 120 packages, which really means I have little time left for lm-sensors (to be
> clear the average package maintainer maintains between 30 - 50 packages).

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.

David

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[Rudolf Marek]

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

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Rudolf Marek]

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


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[David Hubbard]

Hi Rudolf,

On 4/10/07, Rudolf Marek <r.marek@assembler.cz> wrote:
> 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 completely agree.

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

I would be happy to help with quick reviews. I would not be able to do
the "final" "code-perfect" review. But I would be happy to contribute
(more) time for this review process if it would help Jean feel more
comfortable.

> 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 ;).

Ah, Rudolf, you and I are in almost exactly the same position. In every detail.

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

I think our major problem here is that there will not be anyone
capable of Jean's work, and not for a while yet. I would have thought
you, Rudolf, were closest. The hwmon project really needs him.

David

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[David Hubbard]

Hi Rudolf,

On 4/10/07, Rudolf Marek <r.marek@assembler.cz> wrote:
> 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 completely agree.

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

I would be happy to help with quick reviews. I would not be able to do
the "final" "code-perfect" review. But I would be happy to contribute
(more) time for this review process if it would help Jean feel more
comfortable.

> 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 ;).

Ah, Rudolf, you and I are in almost exactly the same position. In every detail.

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

I think our major problem here is that there will not be anyone
capable of Jean's work, and not for a while yet. I would have thought
you, Rudolf, were closest. The hwmon project really needs him.

David

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

[Hans de Goede]

Rudolf Marek wrote:
> Hello all,
> 
> 
> 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.
> 

I like the general direction, but I don't really see a clear difference between 
step 2 and 3, IMO the border between these steps is vague. Also this doesn't 
address who can do (which kinda) reviews.

I've been thinking about a solution for the slow path for new driver inclusion 
myself here is what I propose:

1a) We need a set of review guidelines / a review checklist. Here is a start:
* Must follow kernel coding style guidelines
* sysfs interface must be in accordance with Documentation/hwmon/sysfs
* proper locking to avoid 2 simultaneous attempts to communicate with the
   device when for example multiple sysfs files get read at once.
* check the code for any obvious programming errors, like:
   -not freeing resources (in error paths and in general)
   -overrunning an array
   -not checking return values of calls to other parts of the kernel
   -of by one errors / bad loops
   -etc.
1b) We need to decide somehow who can do reviews. For now I say anyone who
   already maintains atleast one hwmon driver. But thats just a wild shot better
   ideas are welcome.

2) We need a review process for new drivers, suggestion:

1.  Person (the submitter) posts driver
2a. Someone (the reviewer) reviews it according to our checklist / guidelines
     and posts a detailed report of his findings and what needs fixing
2b. The submitter posts a fixed version
2c. The reviewer re-reviews the fixed version and either approves the fixed
     version, goto 3 or points out things that (still) need fixing, goto 2b.
3.  The driver gets send to the -mm tree (marked as EXPERIMENTAL)
4.  Another person (the second reviewer) reviews it, same process as with step
     2, once approved goto 5
5.  Send to Linus tree at the very beginning for the merge cycle still marked
     as EXPERIMENTAL
6.  After quite some time and positive usage reports without any negative
     counter reports a patch gets send to Linux to remove EXPERIMENTAL status.

3) We need a review process for fixes to existing drivers, suggestion:

1. Person (the submitter) posts a patch to an existing driver
2. The driver maintainer is responsible for handling this patch and reviews
    it. If necessary he either modifies the patch himself or asks the submitter
    to make modifications.
3. Once the maintainer is happy with the patch, he sends it to Linus tree at
    the beginning for the merge cycle.


The rationale of doing the new driver thing this way is to avoid having a 
single person who bears end responsibilities for all reviews and thus becomes a 
potential bottleneck. The problem with distributing reviews though is that most 
of us aren't as experienced as Jean is. Thus I decided to just do the review 
twice, to compensate (a bit) for this.

The rationale of doing modifications of existing drivers through the maintainer 
is that he knows the code best, and thus can best judge if fixes are really 
fixes or more bandaids / workarounds. And if these fixes have any unwanted side 
effects.

To give proper credit: the above is heavily inspired by how Fedora handles new 
packages, Fedora has thousands of packages written and maintained by 100's of 
contributers. Using a model where any contributer, once he has taken the first 
horde of becoming a contributer and thus proving (some) competence can review 
other contributers new packages.

Problems with the above, I'm not completely happy with my current proposal for 
deciding who can do reviews. Also I guess that Andrew and Linus would like to 
have a single person to take hwmon patches from, thus we still need someone 
todo the actual collecting of approved patches and sending them to Andrew 
and/or Linus.

Last but not least I want to say that we should not focus too much on review, 
review can only get us sofar. In my (abituguru) experience most real life hwmon 
problems do not come from things easily catched by a review, but rather from 
problems with (certain versions of) the hardware responding different then 
expected. No amount of review will catch these cases, thus we also need to 
concentrate on testing.

For both abituguru drivers I've posted to the forums of the abit websites and 
the lm-sensors list as soon as I got something usable and that way managed to 
build a small team of circa 8 testers for each version, a team which I send 
each update to before sending it for upstream inclusion. Especially for the 
abituguru (rev 1 and 2) driver this has helped my much since this is a strange 
beast. The abituguru3 driver is more straight forward but also there the 
testing by others has been invaluable.


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

+1

Regards,

Hans

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Hans de Goede]

Rudolf Marek wrote:
> Hello all,
> 
> 
> 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.
> 

I like the general direction, but I don't really see a clear difference between 
step 2 and 3, IMO the border between these steps is vague. Also this doesn't 
address who can do (which kinda) reviews.

I've been thinking about a solution for the slow path for new driver inclusion 
myself here is what I propose:

1a) We need a set of review guidelines / a review checklist. Here is a start:
* Must follow kernel coding style guidelines
* sysfs interface must be in accordance with Documentation/hwmon/sysfs
* proper locking to avoid 2 simultaneous attempts to communicate with the
   device when for example multiple sysfs files get read at once.
* check the code for any obvious programming errors, like:
   -not freeing resources (in error paths and in general)
   -overrunning an array
   -not checking return values of calls to other parts of the kernel
   -of by one errors / bad loops
   -etc.
1b) We need to decide somehow who can do reviews. For now I say anyone who
   already maintains atleast one hwmon driver. But thats just a wild shot better
   ideas are welcome.

2) We need a review process for new drivers, suggestion:

1.  Person (the submitter) posts driver
2a. Someone (the reviewer) reviews it according to our checklist / guidelines
     and posts a detailed report of his findings and what needs fixing
2b. The submitter posts a fixed version
2c. The reviewer re-reviews the fixed version and either approves the fixed
     version, goto 3 or points out things that (still) need fixing, goto 2b.
3.  The driver gets send to the -mm tree (marked as EXPERIMENTAL)
4.  Another person (the second reviewer) reviews it, same process as with step
     2, once approved goto 5
5.  Send to Linus tree at the very beginning for the merge cycle still marked
     as EXPERIMENTAL
6.  After quite some time and positive usage reports without any negative
     counter reports a patch gets send to Linux to remove EXPERIMENTAL status.

3) We need a review process for fixes to existing drivers, suggestion:

1. Person (the submitter) posts a patch to an existing driver
2. The driver maintainer is responsible for handling this patch and reviews
    it. If necessary he either modifies the patch himself or asks the submitter
    to make modifications.
3. Once the maintainer is happy with the patch, he sends it to Linus tree at
    the beginning for the merge cycle.


The rationale of doing the new driver thing this way is to avoid having a 
single person who bears end responsibilities for all reviews and thus becomes a 
potential bottleneck. The problem with distributing reviews though is that most 
of us aren't as experienced as Jean is. Thus I decided to just do the review 
twice, to compensate (a bit) for this.

The rationale of doing modifications of existing drivers through the maintainer 
is that he knows the code best, and thus can best judge if fixes are really 
fixes or more bandaids / workarounds. And if these fixes have any unwanted side 
effects.

To give proper credit: the above is heavily inspired by how Fedora handles new 
packages, Fedora has thousands of packages written and maintained by 100's of 
contributers. Using a model where any contributer, once he has taken the first 
horde of becoming a contributer and thus proving (some) competence can review 
other contributers new packages.

Problems with the above, I'm not completely happy with my current proposal for 
deciding who can do reviews. Also I guess that Andrew and Linus would like to 
have a single person to take hwmon patches from, thus we still need someone 
todo the actual collecting of approved patches and sending them to Andrew 
and/or Linus.

Last but not least I want to say that we should not focus too much on review, 
review can only get us sofar. In my (abituguru) experience most real life hwmon 
problems do not come from things easily catched by a review, but rather from 
problems with (certain versions of) the hardware responding different then 
expected. No amount of review will catch these cases, thus we also need to 
concentrate on testing.

For both abituguru drivers I've posted to the forums of the abit websites and 
the lm-sensors list as soon as I got something usable and that way managed to 
build a small team of circa 8 testers for each version, a team which I send 
each update to before sending it for upstream inclusion. Especially for the 
abituguru (rev 1 and 2) driver this has helped my much since this is a strange 
beast. The abituguru3 driver is more straight forward but also there the 
testing by others has been invaluable.


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

+1

Regards,

Hans



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: Hardware monitoring subsystem maintainer position is open

[Jean Delvare]

Hi Hans,

On Tue, 10 Apr 2007 17:40:54 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
> 
> I'm sorry to hear this and I can't help but think that my, erm, rant* yesterday 
> is somehow involved in you making this decision.

Obviously, it is. But please don't feel responsible for it. This just
happened to be the trigger, but that would have happened anyway.

> This was in no way my intention.

I know.

> My intention was to try and make you change how you handle these things,

Except that this isn't how open-source development works. You're not my
boss, you don't get to tell me how I should work. I work the way I
like, and if it doesn't fit with the rest of the community, I better
move on.

> my intention was to make you less of a perfectionist and to distribute 
> the work more, you cannot do everything yourself. I think that if you could 
> change that you would be able to cope with the load better.

Perfectionist - you said it. This is what I am, and this is unlikely to
change in a near future (if ever). But being a subsystem maintainer
requires that you trust contributors to some degree, and you just can't
trust contributors when you're a perfectionist. This means that the
maintainer should be less of a perfectionist than the contributors,
otherwise he/she ends up doing everything by him/herself.

> I think you're experience / knowledge when it comes to hwmon stuff is very 
> valuable and if you leave / quit doing hwmon stuff this would be a big loose.

I didn't say I would leave entirely. I plan to stay around and keep
helping with the lm-sensors project and hwmon drivers. I just don't
want to be the hwmon subsystem maintainer anymore, as I don't fit in
the role and this makes me (and others) unhappy.

-- 
Jean Delvare

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Jean Delvare]

Hi Hans,

On Tue, 10 Apr 2007 17:40:54 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
> 
> I'm sorry to hear this and I can't help but think that my, erm, rant* yesterday 
> is somehow involved in you making this decision.

Obviously, it is. But please don't feel responsible for it. This just
happened to be the trigger, but that would have happened anyway.

> This was in no way my intention.

I know.

> My intention was to try and make you change how you handle these things,

Except that this isn't how open-source development works. You're not my
boss, you don't get to tell me how I should work. I work the way I
like, and if it doesn't fit with the rest of the community, I better
move on.

> my intention was to make you less of a perfectionist and to distribute 
> the work more, you cannot do everything yourself. I think that if you could 
> change that you would be able to cope with the load better.

Perfectionist - you said it. This is what I am, and this is unlikely to
change in a near future (if ever). But being a subsystem maintainer
requires that you trust contributors to some degree, and you just can't
trust contributors when you're a perfectionist. This means that the
maintainer should be less of a perfectionist than the contributors,
otherwise he/she ends up doing everything by him/herself.

> I think you're experience / knowledge when it comes to hwmon stuff is very 
> valuable and if you leave / quit doing hwmon stuff this would be a big loose.

I didn't say I would leave entirely. I plan to stay around and keep
helping with the lm-sensors project and hwmon drivers. I just don't
want to be the hwmon subsystem maintainer anymore, as I don't fit in
the role and this makes me (and others) unhappy.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[David Hubbard]

Hi Jean,

> I didn't say I would leave entirely. I plan to stay around and keep
> helping with the lm-sensors project and hwmon drivers.

Thanks! This is great news.

David

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[David Hubbard]

Hi Jean,

> I didn't say I would leave entirely. I plan to stay around and keep
> helping with the lm-sensors project and hwmon drivers.

Thanks! This is great news.

David

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: Hardware monitoring subsystem maintainer position is open

[Gene Heskett]

On Wednesday 11 April 2007, Jean Delvare wrote:
>Hi Hans,
>
>On Tue, 10 Apr 2007 17:40:54 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>> > I am resigning from my role as hardware monitoring subsystem
>> > (drivers/hwmon) maintainer. This is too much work for me, I do not
>> > have the necessary bandwidth to review all the incoming patches, in
>> > particular new drivers, in a timely manner. Patch authors have been
>> > complaining about this repeatedly. This is no fun for them, and even
>> > less for me, so I'd rather let someone else with more spare time
>> > take care of it. If there are volunteers, this is the right time to
>> > speak up.
>>
>> I'm sorry to hear this and I can't help but think that my, erm, rant*
>> yesterday is somehow involved in you making this decision.
>
>Obviously, it is. But please don't feel responsible for it. This just
>happened to be the trigger, but that would have happened anyway.
>
>> This was in no way my intention.
>
>I know.
>
>> My intention was to try and make you change how you handle these
>> things,
>
>Except that this isn't how open-source development works. You're not my
>boss, you don't get to tell me how I should work. I work the way I
>like, and if it doesn't fit with the rest of the community, I better
>move on.
>
>> my intention was to make you less of a perfectionist and to distribute
>> the work more, you cannot do everything yourself. I think that if you
>> could change that you would be able to cope with the load better.
>
>Perfectionist - you said it. This is what I am, and this is unlikely to
>change in a near future (if ever). But being a subsystem maintainer
>requires that you trust contributors to some degree, and you just can't
>trust contributors when you're a perfectionist. This means that the
>maintainer should be less of a perfectionist than the contributors,
>otherwise he/she ends up doing everything by him/herself.
>
>> I think you're experience / knowledge when it comes to hwmon stuff is
>> very valuable and if you leave / quit doing hwmon stuff this would be
>> a big loose.
>
>I didn't say I would leave entirely. I plan to stay around and keep
>helping with the lm-sensors project and hwmon drivers. I just don't
>want to be the hwmon subsystem maintainer anymore, as I don't fit in
>the role and this makes me (and others) unhappy.

Ouch.  I'm very sorry to read this, Jean.

We don't say thanks for a job very well done often enough, but because of 
you and Bill Wilson (gkrellm) I have been able to track those things that 
have a direct bearing on the health and longevity of my hardware, and 
see, on screen, indicators that tell me its time to pull the flower, 
clean and re-grease it well before the cpu fails.  All with a minimum of 
bumps in the road for several years now.

So, a big tip of the hat, and a heartfelt thank you for all your efforts.  
I hope that the next maintainer is as meticulous.  Those shoes are, I can 
imagine, going to be hard to fill.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Fast ship?  You mean you've never heard of the Millennium Falcon?
		-- Han Solo

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

[Juerg Haefliger]

Hi all,

As pointed out by different people already, this is mainly a process
issue. If we can get enough people together who are willing to
contribute we can make this work. Obviously Jean did a great job (big
thanks!) but I can't blame him for throwing the towel. I was always
amazed at how much time and effort he put into this. This can't be
handled by a single person.

I believe we need to come up with a process (and I like what Hans
suggests) and then need to identify individuals for the different jobs
(reviewers, submitters, ...).

I also think we need to make more use of trac to assign tasks to
people and to provide progress information/reports so that driver
submitters know what's going on and in what stage of the pipeline
their driver currently is.

...juerg (volunteering as a reviewer)




On 4/11/07, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Rudolf Marek wrote:
> > Hello all,
> >
> >
> > 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.
> >
>
> I like the general direction, but I don't really see a clear difference between
> step 2 and 3, IMO the border between these steps is vague. Also this doesn't
> address who can do (which kinda) reviews.
>
> I've been thinking about a solution for the slow path for new driver inclusion
> myself here is what I propose:
>
> 1a) We need a set of review guidelines / a review checklist. Here is a start:
> * Must follow kernel coding style guidelines
> * sysfs interface must be in accordance with Documentation/hwmon/sysfs
> * proper locking to avoid 2 simultaneous attempts to communicate with the
>    device when for example multiple sysfs files get read at once.
> * check the code for any obvious programming errors, like:
>    -not freeing resources (in error paths and in general)
>    -overrunning an array
>    -not checking return values of calls to other parts of the kernel
>    -of by one errors / bad loops
>    -etc.
> 1b) We need to decide somehow who can do reviews. For now I say anyone who
>    already maintains atleast one hwmon driver. But thats just a wild shot better
>    ideas are welcome.
>
> 2) We need a review process for new drivers, suggestion:
>
> 1.  Person (the submitter) posts driver
> 2a. Someone (the reviewer) reviews it according to our checklist / guidelines
>      and posts a detailed report of his findings and what needs fixing
> 2b. The submitter posts a fixed version
> 2c. The reviewer re-reviews the fixed version and either approves the fixed
>      version, goto 3 or points out things that (still) need fixing, goto 2b.
> 3.  The driver gets send to the -mm tree (marked as EXPERIMENTAL)
> 4.  Another person (the second reviewer) reviews it, same process as with step
>      2, once approved goto 5
> 5.  Send to Linus tree at the very beginning for the merge cycle still marked
>      as EXPERIMENTAL
> 6.  After quite some time and positive usage reports without any negative
>      counter reports a patch gets send to Linux to remove EXPERIMENTAL status.
>
> 3) We need a review process for fixes to existing drivers, suggestion:
>
> 1. Person (the submitter) posts a patch to an existing driver
> 2. The driver maintainer is responsible for handling this patch and reviews
>     it. If necessary he either modifies the patch himself or asks the submitter
>     to make modifications.
> 3. Once the maintainer is happy with the patch, he sends it to Linus tree at
>     the beginning for the merge cycle.
>
>
> The rationale of doing the new driver thing this way is to avoid having a
> single person who bears end responsibilities for all reviews and thus becomes a
> potential bottleneck. The problem with distributing reviews though is that most
> of us aren't as experienced as Jean is. Thus I decided to just do the review
> twice, to compensate (a bit) for this.
>
> The rationale of doing modifications of existing drivers through the maintainer
> is that he knows the code best, and thus can best judge if fixes are really
> fixes or more bandaids / workarounds. And if these fixes have any unwanted side
> effects.
>
> To give proper credit: the above is heavily inspired by how Fedora handles new
> packages, Fedora has thousands of packages written and maintained by 100's of
> contributers. Using a model where any contributer, once he has taken the first
> horde of becoming a contributer and thus proving (some) competence can review
> other contributers new packages.
>
> Problems with the above, I'm not completely happy with my current proposal for
> deciding who can do reviews. Also I guess that Andrew and Linus would like to
> have a single person to take hwmon patches from, thus we still need someone
> todo the actual collecting of approved patches and sending them to Andrew
> and/or Linus.
>
> Last but not least I want to say that we should not focus too much on review,
> review can only get us sofar. In my (abituguru) experience most real life hwmon
> problems do not come from things easily catched by a review, but rather from
> problems with (certain versions of) the hardware responding different then
> expected. No amount of review will catch these cases, thus we also need to
> concentrate on testing.
>
> For both abituguru drivers I've posted to the forums of the abit websites and
> the lm-sensors list as soon as I got something usable and that way managed to
> build a small team of circa 8 testers for each version, a team which I send
> each update to before sending it for upstream inclusion. Especially for the
> abituguru (rev 1 and 2) driver this has helped my much since this is a strange
> beast. The abituguru3 driver is more straight forward but also there the
> testing by others has been invaluable.
>
>
> > 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.
> >
>
> +1
>
> Regards,
>
> Hans
>
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Juerg Haefliger]

Hi all,

As pointed out by different people already, this is mainly a process
issue. If we can get enough people together who are willing to
contribute we can make this work. Obviously Jean did a great job (big
thanks!) but I can't blame him for throwing the towel. I was always
amazed at how much time and effort he put into this. This can't be
handled by a single person.

I believe we need to come up with a process (and I like what Hans
suggests) and then need to identify individuals for the different jobs
(reviewers, submitters, ...).

I also think we need to make more use of trac to assign tasks to
people and to provide progress information/reports so that driver
submitters know what's going on and in what stage of the pipeline
their driver currently is.

...juerg (volunteering as a reviewer)




On 4/11/07, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Rudolf Marek wrote:
> > Hello all,
> >
> >
> > 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.
> >
>
> I like the general direction, but I don't really see a clear difference between
> step 2 and 3, IMO the border between these steps is vague. Also this doesn't
> address who can do (which kinda) reviews.
>
> I've been thinking about a solution for the slow path for new driver inclusion
> myself here is what I propose:
>
> 1a) We need a set of review guidelines / a review checklist. Here is a start:
> * Must follow kernel coding style guidelines
> * sysfs interface must be in accordance with Documentation/hwmon/sysfs
> * proper locking to avoid 2 simultaneous attempts to communicate with the
>    device when for example multiple sysfs files get read at once.
> * check the code for any obvious programming errors, like:
>    -not freeing resources (in error paths and in general)
>    -overrunning an array
>    -not checking return values of calls to other parts of the kernel
>    -of by one errors / bad loops
>    -etc.
> 1b) We need to decide somehow who can do reviews. For now I say anyone who
>    already maintains atleast one hwmon driver. But thats just a wild shot better
>    ideas are welcome.
>
> 2) We need a review process for new drivers, suggestion:
>
> 1.  Person (the submitter) posts driver
> 2a. Someone (the reviewer) reviews it according to our checklist / guidelines
>      and posts a detailed report of his findings and what needs fixing
> 2b. The submitter posts a fixed version
> 2c. The reviewer re-reviews the fixed version and either approves the fixed
>      version, goto 3 or points out things that (still) need fixing, goto 2b.
> 3.  The driver gets send to the -mm tree (marked as EXPERIMENTAL)
> 4.  Another person (the second reviewer) reviews it, same process as with step
>      2, once approved goto 5
> 5.  Send to Linus tree at the very beginning for the merge cycle still marked
>      as EXPERIMENTAL
> 6.  After quite some time and positive usage reports without any negative
>      counter reports a patch gets send to Linux to remove EXPERIMENTAL status.
>
> 3) We need a review process for fixes to existing drivers, suggestion:
>
> 1. Person (the submitter) posts a patch to an existing driver
> 2. The driver maintainer is responsible for handling this patch and reviews
>     it. If necessary he either modifies the patch himself or asks the submitter
>     to make modifications.
> 3. Once the maintainer is happy with the patch, he sends it to Linus tree at
>     the beginning for the merge cycle.
>
>
> The rationale of doing the new driver thing this way is to avoid having a
> single person who bears end responsibilities for all reviews and thus becomes a
> potential bottleneck. The problem with distributing reviews though is that most
> of us aren't as experienced as Jean is. Thus I decided to just do the review
> twice, to compensate (a bit) for this.
>
> The rationale of doing modifications of existing drivers through the maintainer
> is that he knows the code best, and thus can best judge if fixes are really
> fixes or more bandaids / workarounds. And if these fixes have any unwanted side
> effects.
>
> To give proper credit: the above is heavily inspired by how Fedora handles new
> packages, Fedora has thousands of packages written and maintained by 100's of
> contributers. Using a model where any contributer, once he has taken the first
> horde of becoming a contributer and thus proving (some) competence can review
> other contributers new packages.
>
> Problems with the above, I'm not completely happy with my current proposal for
> deciding who can do reviews. Also I guess that Andrew and Linus would like to
> have a single person to take hwmon patches from, thus we still need someone
> todo the actual collecting of approved patches and sending them to Andrew
> and/or Linus.
>
> Last but not least I want to say that we should not focus too much on review,
> review can only get us sofar. In my (abituguru) experience most real life hwmon
> problems do not come from things easily catched by a review, but rather from
> problems with (certain versions of) the hardware responding different then
> expected. No amount of review will catch these cases, thus we also need to
> concentrate on testing.
>
> For both abituguru drivers I've posted to the forums of the abit websites and
> the lm-sensors list as soon as I got something usable and that way managed to
> build a small team of circa 8 testers for each version, a team which I send
> each update to before sending it for upstream inclusion. Especially for the
> abituguru (rev 1 and 2) driver this has helped my much since this is a strange
> beast. The abituguru3 driver is more straight forward but also there the
> testing by others has been invaluable.
>
>
> > 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.
> >
>
> +1
>
> Regards,
>
> Hans
>
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Hardware monitoring subsystem maintainer

[Krzysztof Helt]

This is comments from someone who is newbie to this list.

Dnia 11-04-2007 o godz. 11:24 Hans de Goede napisa³(a):
> Rudolf Marek wrote:
> > 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 ;)
> > 

I suppose that 3 reviews are too much.  I would suggest to merge
a driver/patch as experimental just after deep review. The
experimental status can be removed if two persons (including
author if he has tested) can confirm it works. One cannot find
all problems in one turn. They will pop up later, but you will
get wider base of testers if it is in the mainline.

The third review (to removed the experimental status) seems to be
waste of your time.

> 1a) We need a set of review guidelines / a review checklist.
Here is a start:

Maybe these guidelines can be described in more details and with
links or names of documents with more description.

> * Must follow kernel coding style guidelines

Is there any tool to check this? If there is one, a basic
instruction how to use it would be great.

> * sysfs interface must be in accordance with
Documentation/hwmon/sysfs

The documentation is still confusing to me. Can someone of you
update it to answer these questions directly?

A. What is meaning of 0 and 1 values in pwmX_enable ?
B. How to stop the fan (pwmX_enable = 1 and pwmX = 0 was
suggested to someone on the list)?
C. How t o handle situation if the pwm register minimum value (0)
does not stop the fan, but there is a separate bit to do it? (do
stop emulate with the bit when 0 is written to pwmX?)

> * proper locking to avoid 2 simultaneous attempts to
communicate with the
>    device when for example multiple sysfs files get read at once.

An example or two common errors would be great help.

> * check the code for any obvious programming errors, like:
>    -not freeing resources (in error paths and in general)
>    -overrunning an array
>    -not checking return values of calls to other parts of the
kernel
>    -of by one errors / bad loops
>    -etc.

List them, so a newbie can check the code against it.

> 1b) We need to decide somehow who can do reviews. For now I say
anyone who
>    already maintains atleast one hwmon driver. But thats just a
wild shot better
>    ideas are welcome.
> 

There are volunteers already. In order to lessen their work you
can require to follow the guidelines (if they got described) by
authors of patches . The fewer simple errors will reduce your work.

Regards,
Krzysztof

----------------------------------------------------
Diane Wei Liang "OKO JADEITU" - ¶wiatowy bestseller, przeczytaj 
o zderzeniu historii i tera¼niejszo¶ci Chin w znakomitej powie¶ci 
o mi³o¶ci i przebaczeniu - Kliknij i zobacz:
http://klik.wp.pl/?adr=http%3A%2F%2Fksiazki.wp.pl%2Fkatalog%2Fksiazki%2Fksiazka.html%3Fkw%3D36284&sid\x1098



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Hardware monitoring subsystem maintainer positionis open

[Hans de Goede]

Krzysztof Helt wrote:
> This is comments from someone who is newbie to this list.
> 
>> 1a) We need a set of review guidelines / a review checklist.
> Here is a start:
> 
> Maybe these guidelines can be described in more details and with
> links or names of documents with more description.
> 

Yes they should, this was just a quick list. Feel free to help writing a better 
list. And I guess we should put this list in the wiki somewhere.

>> * Must follow kernel coding style guidelines
> 
> Is there any tool to check this? If there is one, a basic
> instruction how to use it would be great.
> 

No tool.

>> * sysfs interface must be in accordance with
> Documentation/hwmon/sysfs
> 
> The documentation is still confusing to me. Can someone of you
> update it to answer these questions directly?
> 
> A. What is meaning of 0 and 1 values in pwmX_enable ?
> B. How to stop the fan (pwmX_enable = 1 and pwmX = 0 was
> suggested to someone on the list)?
> C. How t o handle situation if the pwm register minimum value (0)
> does not stop the fan, but there is a separate bit to do it? (do
> stop emulate with the bit when 0 is written to pwmX?)
> 

I think this is best answered by Jean and/or Mark

>> * proper locking to avoid 2 simultaneous attempts to
> communicate with the
>>    device when for example multiple sysfs files get read at once.
> 
> An example or two common errors would be great help.
> 

Erm, if  someone doesn't know what this means / how to look for this he 
shouldn't be reviewing a driver.

>> * check the code for any obvious programming errors, like:
>>    -not freeing resources (in error paths and in general)
>>    -overrunning an array
>>    -not checking return values of calls to other parts of the
> kernel
>>    -of by one errors / bad loops
>>    -etc.
> 
> List them, so a newbie can check the code against it.
> 

The etc. was because I'm sure there are more but I couldn't come up with any 
right there and then. And again a newbie shouldn't be reviewing, he should 
start reading some book in device drivers writing a driver or two himself get 
those reviewed and then he should no longer be a newbie :)

>> 1b) We need to decide somehow who can do reviews. For now I say
> anyone who
>>    already maintains atleast one hwmon driver. But thats just a
> wild shot better
>>    ideas are welcome.
>>
> 
> There are volunteers already. In order to lessen their work you
> can require to follow the guidelines (if they got described) by
> authors of patches .

Yes ofcourse authors should follow the guidelines, and check they did 
themselves before submitting. Also its great that there are volunteers, but 
reviewing does require a certain level of competence. There are many other ways 
to help out for those without the necessary skills todo the reviewing.

For example you could check out the 3.0.0 branch:
svn checkout http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0

Edit lib/chips.c, goto the long array at the end and comment any entries for 
chips you have. Optionally edit prog/sensors/main.c goto the array near the end 
and again comment entries for chips you have.

Build and install lm-sensors-3.0.0 and let us know how it works, despite the 
commenting it should still recognize your cips and print the same info as usual 
(it can now dynamicly recognize new/unknown chips as long as the kernel 
supports them). When you skipped the optional step run the sensors command as 
'sensors -g', the normal sensors command will be borked if you skipped this step.

Thanks & Regards,

Hans

Re: [lm-sensors] Hardware monitoring subsystem

[Hans de Goede]

Krzysztof Helt wrote:
> This is comments from someone who is newbie to this list.
> 
>> 1a) We need a set of review guidelines / a review checklist.
> Here is a start:
> 
> Maybe these guidelines can be described in more details and with
> links or names of documents with more description.
> 

Yes they should, this was just a quick list. Feel free to help writing a better 
list. And I guess we should put this list in the wiki somewhere.

>> * Must follow kernel coding style guidelines
> 
> Is there any tool to check this? If there is one, a basic
> instruction how to use it would be great.
> 

No tool.

>> * sysfs interface must be in accordance with
> Documentation/hwmon/sysfs
> 
> The documentation is still confusing to me. Can someone of you
> update it to answer these questions directly?
> 
> A. What is meaning of 0 and 1 values in pwmX_enable ?
> B. How to stop the fan (pwmX_enable = 1 and pwmX = 0 was
> suggested to someone on the list)?
> C. How t o handle situation if the pwm register minimum value (0)
> does not stop the fan, but there is a separate bit to do it? (do
> stop emulate with the bit when 0 is written to pwmX?)
> 

I think this is best answered by Jean and/or Mark

>> * proper locking to avoid 2 simultaneous attempts to
> communicate with the
>>    device when for example multiple sysfs files get read at once.
> 
> An example or two common errors would be great help.
> 

Erm, if  someone doesn't know what this means / how to look for this he 
shouldn't be reviewing a driver.

>> * check the code for any obvious programming errors, like:
>>    -not freeing resources (in error paths and in general)
>>    -overrunning an array
>>    -not checking return values of calls to other parts of the
> kernel
>>    -of by one errors / bad loops
>>    -etc.
> 
> List them, so a newbie can check the code against it.
> 

The etc. was because I'm sure there are more but I couldn't come up with any 
right there and then. And again a newbie shouldn't be reviewing, he should 
start reading some book in device drivers writing a driver or two himself get 
those reviewed and then he should no longer be a newbie :)

>> 1b) We need to decide somehow who can do reviews. For now I say
> anyone who
>>    already maintains atleast one hwmon driver. But thats just a
> wild shot better
>>    ideas are welcome.
>>
> 
> There are volunteers already. In order to lessen their work you
> can require to follow the guidelines (if they got described) by
> authors of patches .

Yes ofcourse authors should follow the guidelines, and check they did 
themselves before submitting. Also its great that there are volunteers, but 
reviewing does require a certain level of competence. There are many other ways 
to help out for those without the necessary skills todo the reviewing.

For example you could check out the 3.0.0 branch:
svn checkout http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0

Edit lib/chips.c, goto the long array at the end and comment any entries for 
chips you have. Optionally edit prog/sensors/main.c goto the array near the end 
and again comment entries for chips you have.

Build and install lm-sensors-3.0.0 and let us know how it works, despite the 
commenting it should still recognize your cips and print the same info as usual 
(it can now dynamicly recognize new/unknown chips as long as the kernel 
supports them). When you skipped the optional step run the sensors command as 
'sensors -g', the normal sensors command will be borked if you skipped this step.

Thanks & Regards,

Hans


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Hardware monitoring subsystem maintainer

[Jean Delvare]

Hi Krzysztof,

On Thu, 12 Apr 2007 07:57:28 +0200, Krzysztof Helt wrote:
> The documentation is still confusing to me. Can someone of you
> update it to answer these questions directly?

This is rather off-topic for this thread, so I removed LKML from Cc.

> A. What is meaning of 0 and 1 values in pwmX_enable ?

This is already documented.

> B. How to stop the fan (pwmX_enable = 1 and pwmX = 0 was
> suggested to someone on the list)?

Yes, this is the correct method.

> C. How t o handle situation if the pwm register minimum value (0)
> does not stop the fan, but there is a separate bit to do it? (do
> stop emulate with the bit when 0 is written to pwmX?)

Yes, again that's the correct method.

You seem to understand how it works just fine, so instead of asking us
to update the document, why don't you do it yourself and send us a
patch?

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Hardware monitoring subsystem maintainer positionis open

[Dmitry Torokhov]

Hi,

On Thursday 12 April 2007 03:27, Hans de Goede wrote:
> Krzysztof Helt wrote:
> 
> >> * Must follow kernel coding style guidelines
> > 
> > Is there any tool to check this? If there is one, a basic
> > instruction how to use it would be great.
> > 
> 
> No tool.

Passing new drivres through scripts/Lindent and analyzing the
dirrerences can highlight differences between kernel style and
author's (note that I do not advocate mechanically passing
everything though Lindent).

-- 
Dmitry

Re: [lm-sensors]

[Dmitry Torokhov]

Hi,

On Thursday 12 April 2007 03:27, Hans de Goede wrote:
> Krzysztof Helt wrote:
> 
> >> * Must follow kernel coding style guidelines
> > 
> > Is there any tool to check this? If there is one, a basic
> > instruction how to use it would be great.
> > 
> 
> No tool.

Passing new drivres through scripts/Lindent and analyzing the
dirrerences can highlight differences between kernel style and
author's (note that I do not advocate mechanically passing
everything though Lindent).

-- 
Dmitry

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[Mark M. Hoffman]

Hi Jean, et al:

* Jean Delvare <khali@linux-fr.org> [2007-04-10 15:02:27 +0200]:
> I am resigning from my role as hardware monitoring subsystem
> (drivers/hwmon) maintainer. This is too much work for me, I do not have
> the necessary bandwidth to review all the incoming patches, in
> particular new drivers, in a timely manner. Patch authors have been
> complaining about this repeatedly. This is no fun for them, and even
> less for me, so I'd rather let someone else with more spare time take
> care of it. If there are volunteers, this is the right time to speak up.
> 
> I will still be maintaining the individual hardware monitoring drivers
> I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> as well as the I2C subsystem. No change here.
> 
> I will continue to feed -mm with pending hwmon patches until 2.6.21
> final is released, then I'll send everything I have to Linus for
> 2.6.22-rc1, the last of which will be:
>  (...)

/me throws hat in

I volunteer to become the new MAINTAINER, but in a much more limited sense
of the term than Jean is/was.  I can take care of a couple git trees, and do
some detailed reviews when I have time.  For the most part, I will have to
rely on others to do reviews as well.

I would not be volunteering for this role, if Juerg and others had not also
volunteered to be more active reviewers.

As for the discussions later in this thread about process... IMHO that's a
little premature.  I intend to get brand new stuff into -mm perhaps a little
earlier than Jean did... but it still ain't going to Linus before it's ready.
Other than that, I would rather just see what works for me and for you (other
hwmon authors).

Assuming no one else wants the job (ruik?) I'll start working with Jean to
get things set up as soon as I can.

Thanks & regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Mark M. Hoffman]

Hi Jean, et al:

* Jean Delvare <khali@linux-fr.org> [2007-04-10 15:02:27 +0200]:
> I am resigning from my role as hardware monitoring subsystem
> (drivers/hwmon) maintainer. This is too much work for me, I do not have
> the necessary bandwidth to review all the incoming patches, in
> particular new drivers, in a timely manner. Patch authors have been
> complaining about this repeatedly. This is no fun for them, and even
> less for me, so I'd rather let someone else with more spare time take
> care of it. If there are volunteers, this is the right time to speak up.
> 
> I will still be maintaining the individual hardware monitoring drivers
> I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> as well as the I2C subsystem. No change here.
> 
> I will continue to feed -mm with pending hwmon patches until 2.6.21
> final is released, then I'll send everything I have to Linus for
> 2.6.22-rc1, the last of which will be:
>  (...)

/me throws hat in

I volunteer to become the new MAINTAINER, but in a much more limited sense
of the term than Jean is/was.  I can take care of a couple git trees, and do
some detailed reviews when I have time.  For the most part, I will have to
rely on others to do reviews as well.

I would not be volunteering for this role, if Juerg and others had not also
volunteered to be more active reviewers.

As for the discussions later in this thread about process... IMHO that's a
little premature.  I intend to get brand new stuff into -mm perhaps a little
earlier than Jean did... but it still ain't going to Linus before it's ready.
Other than that, I would rather just see what works for me and for you (other
hwmon authors).

Assuming no one else wants the job (ruik?) I'll start working with Jean to
get things set up as soon as I can.

Thanks & regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[Juerg Haefliger]

Hi Mark,


On 4/15/07, Mark M. Hoffman <mhoffman@lightlink.com> wrote:
> Hi Jean, et al:
>
> * Jean Delvare <khali@linux-fr.org> [2007-04-10 15:02:27 +0200]:
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
> >
> > I will still be maintaining the individual hardware monitoring drivers
> > I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> > as well as the I2C subsystem. No change here.
> >
> > I will continue to feed -mm with pending hwmon patches until 2.6.21
> > final is released, then I'll send everything I have to Linus for
> > 2.6.22-rc1, the last of which will be:
> >  (...)
>
> /me throws hat in
>
> I volunteer to become the new MAINTAINER, but in a much more limited sense
> of the term than Jean is/was.  I can take care of a couple git trees, and do
> some detailed reviews when I have time.  For the most part, I will have to
> rely on others to do reviews as well.
>
> I would not be volunteering for this role, if Juerg and others had not also
> volunteered to be more active reviewers.
>
> As for the discussions later in this thread about process... IMHO that's a
> little premature.  I intend to get brand new stuff into -mm perhaps a little
> earlier than Jean did... but it still ain't going to Linus before it's ready.
> Other than that, I would rather just see what works for me and for you (other
> hwmon authors).
>
> Assuming no one else wants the job (ruik?) I'll start working with Jean to
> get things set up as soon as I can.

Thanks a lot Mark! I'm sure everybody appreciates very much that you
volunteer for this position.

...juerg


> Thanks & regards,
>
> --
> Mark M. Hoffman
> mhoffman@lightlink.com
>
>

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Juerg Haefliger]

Hi Mark,


On 4/15/07, Mark M. Hoffman <mhoffman@lightlink.com> wrote:
> Hi Jean, et al:
>
> * Jean Delvare <khali@linux-fr.org> [2007-04-10 15:02:27 +0200]:
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
> >
> > I will still be maintaining the individual hardware monitoring drivers
> > I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> > as well as the I2C subsystem. No change here.
> >
> > I will continue to feed -mm with pending hwmon patches until 2.6.21
> > final is released, then I'll send everything I have to Linus for
> > 2.6.22-rc1, the last of which will be:
> >  (...)
>
> /me throws hat in
>
> I volunteer to become the new MAINTAINER, but in a much more limited sense
> of the term than Jean is/was.  I can take care of a couple git trees, and do
> some detailed reviews when I have time.  For the most part, I will have to
> rely on others to do reviews as well.
>
> I would not be volunteering for this role, if Juerg and others had not also
> volunteered to be more active reviewers.
>
> As for the discussions later in this thread about process... IMHO that's a
> little premature.  I intend to get brand new stuff into -mm perhaps a little
> earlier than Jean did... but it still ain't going to Linus before it's ready.
> Other than that, I would rather just see what works for me and for you (other
> hwmon authors).
>
> Assuming no one else wants the job (ruik?) I'll start working with Jean to
> get things set up as soon as I can.

Thanks a lot Mark! I'm sure everybody appreciates very much that you
volunteer for this position.

...juerg


> Thanks & regards,
>
> --
> Mark M. Hoffman
> mhoffman@lightlink.com
>
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[Rudolf Marek]

> Assuming no one else wants the job (ruik?) I'll start working with Jean to
> get things set up as soon as I can.

No, I already wrote that I do not have enough time :/ I will try to support you
at least with the reviews. Cool would be if someone would take a support role,
because I simply do not have much time left for that.

Thanks,
Rudolf

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Rudolf Marek]

> Assuming no one else wants the job (ruik?) I'll start working with Jean to
> get things set up as soon as I can.

No, I already wrote that I do not have enough time :/ I will try to support you
at least with the reviews. Cool would be if someone would take a support role,
because I simply do not have much time left for that.

Thanks,
Rudolf

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[Jean Delvare]

Hi Mark,

On Sun, 15 Apr 2007 11:03:20 -0400, Mark M. Hoffman wrote:
> Hi Jean, et al:
> 
> * Jean Delvare <khali@linux-fr.org> [2007-04-10 15:02:27 +0200]:
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
> > 
> > I will still be maintaining the individual hardware monitoring drivers
> > I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> > as well as the I2C subsystem. No change here.
> > 
> > I will continue to feed -mm with pending hwmon patches until 2.6.21
> > final is released, then I'll send everything I have to Linus for
> > 2.6.22-rc1, the last of which will be:
> >  (...)
> 
> /me throws hat in
> 
> I volunteer to become the new MAINTAINER, but in a much more limited sense
> of the term than Jean is/was.  I can take care of a couple git trees, and do
> some detailed reviews when I have time.  For the most part, I will have to
> rely on others to do reviews as well.

This is excellent news, thanks for volunteering. We have been working
together for a long time now and I'm happy to see you take the lead.
You have my blessing.

> I would not be volunteering for this role, if Juerg and others had not also
> volunteered to be more active reviewers.
> 
> As for the discussions later in this thread about process... IMHO that's a
> little premature.  I intend to get brand new stuff into -mm perhaps a little
> earlier than Jean did... but it still ain't going to Linus before it's ready.
> Other than that, I would rather just see what works for me and for you (other
> hwmon authors).
> 
> Assuming no one else wants the job (ruik?) I'll start working with Jean to
> get things set up as soon as I can.

Great. I'll help you make the transition as smooth as possible.

-- 
Jean Delvare

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Jean Delvare]

Hi Mark,

On Sun, 15 Apr 2007 11:03:20 -0400, Mark M. Hoffman wrote:
> Hi Jean, et al:
> 
> * Jean Delvare <khali@linux-fr.org> [2007-04-10 15:02:27 +0200]:
> > I am resigning from my role as hardware monitoring subsystem
> > (drivers/hwmon) maintainer. This is too much work for me, I do not have
> > the necessary bandwidth to review all the incoming patches, in
> > particular new drivers, in a timely manner. Patch authors have been
> > complaining about this repeatedly. This is no fun for them, and even
> > less for me, so I'd rather let someone else with more spare time take
> > care of it. If there are volunteers, this is the right time to speak up.
> > 
> > I will still be maintaining the individual hardware monitoring drivers
> > I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> > as well as the I2C subsystem. No change here.
> > 
> > I will continue to feed -mm with pending hwmon patches until 2.6.21
> > final is released, then I'll send everything I have to Linus for
> > 2.6.22-rc1, the last of which will be:
> >  (...)
> 
> /me throws hat in
> 
> I volunteer to become the new MAINTAINER, but in a much more limited sense
> of the term than Jean is/was.  I can take care of a couple git trees, and do
> some detailed reviews when I have time.  For the most part, I will have to
> rely on others to do reviews as well.

This is excellent news, thanks for volunteering. We have been working
together for a long time now and I'm happy to see you take the lead.
You have my blessing.

> I would not be volunteering for this role, if Juerg and others had not also
> volunteered to be more active reviewers.
> 
> As for the discussions later in this thread about process... IMHO that's a
> little premature.  I intend to get brand new stuff into -mm perhaps a little
> earlier than Jean did... but it still ain't going to Linus before it's ready.
> Other than that, I would rather just see what works for me and for you (other
> hwmon authors).
> 
> Assuming no one else wants the job (ruik?) I'll start working with Jean to
> get things set up as soon as I can.

Great. I'll help you make the transition as smooth as possible.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Hardware monitoring subsystem maintainer position

[Ivo Manca]

Hey Jean,

Better late then never, but I wanted to thank you for the effor you've put 
in it. Even though I'm not on this list for very long and even though I've 
only contacted you for suggestions with the new sensors-detect script, 
you've helped us a lot and you always responded .

I'm glad to hear that you're not leaving completely and I hope you'll be 
able to enjoy working for lm-sensors again, now you're no longer the 
maintainer.

I would also like to thank Mark M. Hoffman for voluntering for this 
positition.

Kind Regards,
Ivo Manca

----- Original Message ----- 
From: "Jean Delvare" <khali@linux-fr.org>
To: "LM Sensors" <lm-sensors@lm-sensors.org>; "LKML" 
<linux-kernel@vger.kernel.org>
Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>; "Hans de Goede" 
<j.w.r.degoede@hhs.nl>
Sent: Tuesday 10 April 2007 15:02
Subject: [lm-sensors] Hardware monitoring subsystem maintainer position 
isopen


> Hi all,
>
> I am resigning from my role as hardware monitoring subsystem
> (drivers/hwmon) maintainer. This is too much work for me, I do not have
> the necessary bandwidth to review all the incoming patches, in
> particular new drivers, in a timely manner. Patch authors have been
> complaining about this repeatedly. This is no fun for them, and even
> less for me, so I'd rather let someone else with more spare time take
> care of it. If there are volunteers, this is the right time to speak up.
>
> I will still be maintaining the individual hardware monitoring drivers
> I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90)
> as well as the I2C subsystem. No change here.
>
> I will continue to feed -mm with pending hwmon patches until 2.6.21
> final is released, then I'll send everything I have to Linus for
> 2.6.22-rc1, the last of which will be:
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> ---
> MAINTAINERS |    5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- linux-2.6.21-rc6.orig/MAINTAINERS 2007-04-10 13:49:09.000000000 +0200
> +++ linux-2.6.21-rc6/MAINTAINERS 2007-04-10 14:28:31.000000000 +0200
> @@ -1467,12 +1467,9 @@ W: http://gigaset307x.sourceforge.net/
> S: Maintained
>
> HARDWARE MONITORING
> -P: Jean Delvare
> -M: khali@linux-fr.org
> L: lm-sensors@lm-sensors.org
> W: http://www.lm-sensors.org/
> -T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-hwmon/
> -S: Maintained
> +S: Orphan
>
> HARDWARE RANDOM NUMBER GENERATOR CORE
> P: Michael Buesch
>
> Then I'll probably keep an eye on hwmon in Linus' tree until 2.6.22
> final is released, and after that I'm done with it.
>
> -- 
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors