[lm-sensors] concentrate efforts on libsensor-3.x or also add

[lm-sensors] concentrate efforts on libsensor-3.x or also add

[Hans de Goede]

Hi All,

I'm wondering when are libsensors-3.x alpha / beta releases planned? I'm 
tending towards not adding support for the abituguru3 and the f71882fg to 
lm_sensors-2.10.x because 3.x will hopefully soon be available and I can spend 
my time only once. OTOH, the 2.10.x line may continue to exist and be used for 
a while so it might be a good idea to add support there too, what do you guys 
think?

Regards,

hans


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

Re: [lm-sensors] concentrate efforts on libsensor-3.x or also add

[Jean Delvare]

Hi Hans,

On Mon, 02 Jul 2007 17:12:13 +0200, Hans de Goede wrote:
> I'm wondering when are libsensors-3.x alpha / beta releases planned? I'm 
> tending towards not adding support for the abituguru3 and the f71882fg to 
> lm_sensors-2.10.x because 3.x will hopefully soon be available and I can spend 
> my time only once. OTOH, the 2.10.x line may continue to exist and be used for 
> a while so it might be a good idea to add support there too, what do you guys 
> think?

This is a very valid question. The problem is that there is no release
date planned for 3.x. Originally, Mark wanted to release it on July
2007, i.e. now... and as you can see it didn't happen. I changed the
milestone to September 2007 in trac, but the truth is, I simply don't
know if I'll be able to put enough time into libsensors by then to make
it really happen. There's still a lot to do, despite the fact that
things look good from the outside, and seem to work. I want us to
review the library interface entirely, killing what's not needed, and
reworking what needs to be. As we're going for a new major .so number,
we really need to start from a clean design, not quickly adjusted code
based on the old library.

I am not interested in making formal alpha releases. People can pick
from SVN anytime if they want to. I am not too interested in numbered
beta releases either. I'd rather generate nightly snapshots as we do for
the other branches, once we feel it's time to do so.

2.10.4 will be released very soon. And after that I think we'll have at
least 2.10.5 before the 2.x branch can go to sleep. And distributions
need time before they switch to a new branch of a product. So I don't
think you can spare the time needed to add support for your chips to
the 2.10.x branch, unless you don't want distribution users to use your
drivers before another 6 months, at best. Only after 3.x is released,
we can stop adding support for new chips in 2.x, methinks.

Not to say that you shouldn't ask your testers to try branch 3.x now as
well, just to make sure it works as intended - but that's not what
regular users will have in their distributions before a while.

-- 
Jean Delvare

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

Re: [lm-sensors] concentrate efforts on libsensor-3.x or also add

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Mon, 02 Jul 2007 17:12:13 +0200, Hans de Goede wrote:
>> I'm wondering when are libsensors-3.x alpha / beta releases planned? I'm 
>> tending towards not adding support for the abituguru3 and the f71882fg to 
>> lm_sensors-2.10.x because 3.x will hopefully soon be available and I can spend 
>> my time only once. OTOH, the 2.10.x line may continue to exist and be used for 
>> a while so it might be a good idea to add support there too, what do you guys 
>> think?
> 
> This is a very valid question. The problem is that there is no release
> date planned for 3.x. Originally, Mark wanted to release it on July
> 2007, i.e. now... and as you can see it didn't happen. I changed the
> milestone to September 2007 in trac, but the truth is, I simply don't
> know if I'll be able to put enough time into libsensors by then to make
> it really happen. There's still a lot to do, despite the fact that
> things look good from the outside, and seem to work. I want us to
> review the library interface entirely, killing what's not needed, and
> reworking what needs to be. As we're going for a new major .so number,
> we really need to start from a clean design, not quickly adjusted code
> based on the old library.
> 

<sigh>

This may sound a bit more harsh then its intended, but thats just my writing 
style + me writing in a foreign language, so please read this as its intented, 
much more as feedback then as criticism.

First of all who is running the show here you or Mark? Having 2 captains on a 
ship doesn't work all that well IMHO.

Second, this is not what was agreed too when the generic chip support was first 
merged, I argued that it should go to the 2.x branch, which it could have (and 
still can) since if its added to the 2.x branch as was suggested, so that it 
only gets used for new / unknown chips, then it cannot cause regressions for 
existing users, as those will never enter a codepath which uses it.

Also the generic chip support was designed exactly to stop the mind numbing 
pain of having to write similar but subtile different printing routines for 
each chip, pain which now is being induced upon all of us be delaying a release 
of libsensors with generic chipsupport added.

With that said, I must say I agree with the cleaning happening for the 3.x 
branch. I also technically agree with taking a good look at the API+ABI before
releasing a new soname version, I would like to notice though this wasn't on 
the original roadmap and working on features only to have them delayed by new 
stuff being put on the roadmap makes me grumpy. Esp. because this (thinking of 
new things todo for release) is a process which can be repeated endlessly, thus 
delaying the release of said new features endlessly.

So can we please create a new (short) roadmap + timeline for 3.x and stick to it?

> 2.10.4 will be released very soon. And after that I think we'll have at
> least 2.10.5 before the 2.x branch can go to sleep. And distributions
> need time before they switch to a new branch of a product. So I don't
> think you can spare the time needed to add support for your chips to
> the 2.10.x branch, unless you don't want distribution users to use your
> drivers before another 6 months, at best. Only after 3.x is released,
> we can stop adding support for new chips in 2.x, methinks.
> 

Unfortunately I agree. I say Unfortunately because that means I have to write 
libsensors + sensors 2.x support for the abituguru3 and the fintek f71882fg.

I see 2 options here:
1) I'll scramble to write abituguru3 and fintek f71882fg support for 2.10.x
    before the july 8th deadline. If we go this way, is it ok to directly
    commit this to svn? (I might need slightly more time in which case I would
    like to ask for a short delay, but I'll try to make the july 8th deadline)

2) Do a 2.11.0 (with RC / beta first) soon after 2.10.4 with the current
    generic chip support code from 3.x merged in the way it was originally
    intented (iow only comes into play for unknown chips)

I prefer 2, because that means that we will have a 2.x for more conservative 
users, which will automatically work with new chips as they are added to the 
kernel, and this might save us from having todo a 2.10.6 (2.11.0 is about as 
much work as 2.10.5 I guess).

Please let me know which one it will be, then I'll start working on the choosen 
path.

> Not to say that you shouldn't ask your testers to try branch 3.x now as
> well, just to make sure it works as intended - but that's not what
> regular users will have in their distributions before a while.
> 

I'm asking and they are testing it with success.

Regards,

Hans

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

Re: [lm-sensors] concentrate efforts on libsensor-3.x or also add

[David Hubbard]

I'll chime in with my opinion, but take it with a pinch of salt... or
a bucket full.

> <sigh>
>
> This may sound a bit more harsh then its intended, but thats just my writing
> style + me writing in a foreign language, so please read this as its intented,
> much more as feedback then as criticism.
>
> First of all who is running the show here you or Mark? Having 2 captains on a
> ship doesn't work all that well IMHO.

I think the change over to having Mark in charge is going very well.
Jean is still a big contributor. As in, he contributes a hundred times
more to the project than I do. For example, he had a week to devote to
moving sensors 3.x forward. I haven't had the time to do that!

> Second, this is not what was agreed too when the generic chip support was first
> merged, I argued that it should go to the 2.x branch, which it could have (and
> still can) since if its added to the 2.x branch as was suggested, so that it
> only gets used for new / unknown chips, then it cannot cause regressions for
> existing users, as those will never enter a codepath which uses it.
>
> Also the generic chip support was designed exactly to stop the mind numbing
> pain of having to write similar but subtile different printing routines for
> each chip, pain which now is being induced upon all of us be delaying a release
> of libsensors with generic chipsupport added.
>
> With that said, I must say I agree with the cleaning happening for the 3.x
> branch. I also technically agree with taking a good look at the API+ABI before
> releasing a new soname version, I would like to notice though this wasn't on
> the original roadmap and working on features only to have them delayed by new
> stuff being put on the roadmap makes me grumpy. Esp. because this (thinking of
> new things todo for release) is a process which can be repeated endlessly, thus
> delaying the release of said new features endlessly.
>
> So can we please create a new (short) roadmap + timeline for 3.x and stick to it?
>
> > 2.10.4 will be released very soon. And after that I think we'll have at
> > least 2.10.5 before the 2.x branch can go to sleep. And distributions
> > need time before they switch to a new branch of a product. So I don't
> > think you can spare the time needed to add support for your chips to
> > the 2.10.x branch, unless you don't want distribution users to use your
> > drivers before another 6 months, at best. Only after 3.x is released,
> > we can stop adding support for new chips in 2.x, methinks.
> >
>
> Unfortunately I agree. I say Unfortunately because that means I have to write
> libsensors + sensors 2.x support for the abituguru3 and the fintek f71882fg.
>
> I see 2 options here:
> 1) I'll scramble to write abituguru3 and fintek f71882fg support for 2.10.x
>     before the july 8th deadline. If we go this way, is it ok to directly
>     commit this to svn? (I might need slightly more time in which case I would
>     like to ask for a short delay, but I'll try to make the july 8th deadline)
>
> 2) Do a 2.11.0 (with RC / beta first) soon after 2.10.4 with the current
>     generic chip support code from 3.x merged in the way it was originally
>     intented (iow only comes into play for unknown chips)
>
> I prefer 2, because that means that we will have a 2.x for more conservative
> users, which will automatically work with new chips as they are added to the
> kernel, and this might save us from having todo a 2.10.6 (2.11.0 is about as
> much work as 2.10.5 I guess).
>
> Please let me know which one it will be, then I'll start working on the choosen
> path.

I remember the original discussion about generic chip support. I think
adding it to sensors 2.x would smooth the transition to 3.x, but IIRC
Jean was right, we would duplicate the code in 2.x and 3.x. I think
it's completely within reason to put generic chip support in 2.x and
keep it carefully under control so it doesn't cause maintenance
headaches.

I'm not in any position to really contribute to the abit uguru3 or
fintek f71882fg drivers, so all of this is probably irrelevant.

David

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

Re: [lm-sensors] concentrate efforts on libsensor-3.x or also add

[Jean Delvare]

Hi Hans,

On Wed, 04 Jul 2007 06:52:42 +0200, Hans de Goede wrote:
> First of all who is running the show here you or Mark? Having 2 captains on a 
> ship doesn't work all that well IMHO.

Who said there was a captain? ;)

Mark initiated the lm-sensors-3.0.0 branch. You populated it with your
student's work and fixed it a bit. I am now reviewing it and cleaning
it up. Everyone of us has spent time and energy when he could. This is
how small open-source projects work, you shouldn't be surprised.

Mark has limited time to work on the lm-sensors project. Well, we all
do, but I think I can assert that I have more time for the project than
Mark does, at the time being. And Mark agreed to take over me as the new
hwmon subsystem maintainer. All the time he puts there, he can't put in
libsensors.

I'm not sure what worries you. I don't think that Mark and myself are
in disagreement on the course of action we should take.

> Second, this is not what was agreed too when the generic chip support was first 
> merged, I argued that it should go to the 2.x branch, which it could have (and 
> still can) since if its added to the 2.x branch as was suggested, so that it 
> only gets used for new / unknown chips, then it cannot cause regressions for 
> existing users, as those will never enter a codepath which uses it.

You forget to mention that the generic chip support relies on the new
sensors_feature_get_type interface. This means that not only
libsensors needs to be modified, but also sensors and all the other
tools which rely on libsensors. I am not willing to ask the developers
of these tools to add support for a preliminary version of the generic
chip support now, and then again for libsensors.so.4 (as we already
know it will not be compatible.) And having support in only sensors and
not the other tools isn't really an option either, users would complain
loudly.

When I proposed to add generic chip support to the 2.x branch, I had
not realized the compatibility issues that were involved. I agree that
it added unneeded constraints to your student's work and I'm sorry
about that. But now that we decided to add the code to the 3.x branch
and the biggest part of the work is done there, there's no way we step
back and start it all over again. A decision was made and we will stick
to it.

> Also the generic chip support was designed exactly to stop the mind numbing 
> pain of having to write similar but subtile different printing routines for 
> each chip, pain which now is being induced upon all of us be delaying a release 
> of libsensors with generic chipsupport added.

The pain is mainly on the user's side, not ours. Adding support for a
new chip to libsensors.so.3  and sensors is not that difficult. It's a
matter of 15 minutes for us, I'd say. Copy and paste isn't funny, but
it's not difficult.

> With that said, I must say I agree with the cleaning happening for the 3.x 
> branch. I also technically agree with taking a good look at the API+ABI before
> releasing a new soname version, I would like to notice though this wasn't on 
> the original roadmap and working on features only to have them delayed by new 
> stuff being put on the roadmap makes me grumpy. Esp. because this (thinking of 
> new things todo for release) is a process which can be repeated endlessly, thus 
> delaying the release of said new features endlessly.

I don't plan to wait for libsensors.so.4 to be perfect before we
release it. All I want is that the interface is clean enough so that we
can be reasonably certain we won't have to change it in the next 8
years. The rest can be improved endlessly, but later. I was hoping to
have the time to look at the interface last week, but I did not. This
is still at the top of my todo list, but I have a lot to do for my day
job again.

> So can we please create a new (short) roadmap + timeline for 3.x and stick to it?

See http://www.lm-sensors.org/roadmap

This is the roadmap, in terms of remaining tasks. It can be argued
whether these are all blockers for 3.0.0. Some of the items could
probably be postponed to 3.0.1. For example, #2174 (Add 'include'
functionality for sensors.conf) is in no way required for 3.0.0.

If there are other things you think need to be done for 3.0.0, please
add them. And feel free to create a new 3.0.1 milestone and propose
moving some of the items from 3.0.0 to 3.0.1 if they don't look like
blockers to you.

> > 2.10.4 will be released very soon. And after that I think we'll have at
> > least 2.10.5 before the 2.x branch can go to sleep. And distributions
> > need time before they switch to a new branch of a product. So I don't
> > think you can spare the time needed to add support for your chips to
> > the 2.10.x branch, unless you don't want distribution users to use your
> > drivers before another 6 months, at best. Only after 3.x is released,
> > we can stop adding support for new chips in 2.x, methinks.
> 
> Unfortunately I agree. I say Unfortunately because that means I have to write 
> libsensors + sensors 2.x support for the abituguru3 and the fintek f71882fg.

As I wrote above, it's not that difficult.

> I see 2 options here:
> 1) I'll scramble to write abituguru3 and fintek f71882fg support for 2.10.x
>     before the july 8th deadline. If we go this way, is it ok to directly
>     commit this to svn? (I might need slightly more time in which case I would
>     like to ask for a short delay, but I'll try to make the july 8th deadline)

If you need more time, just tell me. The deadline is not set in stone,
we can change it.

> 2) Do a 2.11.0 (with RC / beta first) soon after 2.10.4 with the current
>     generic chip support code from 3.x merged in the way it was originally
>     intented (iow only comes into play for unknown chips)

Please, no. This would be a waste of your time and mine. The current
2.x method is bad (otherwise we wouldn't be working on 3.x) but it is
mastered by us and well understood by distributions, application
authors and users. We have been living with it for 8 years, a couple
additional months really aren't a problem. If you have time to put in
the project, please contribute to 3.x (or help with support so that I
can contribute to 3.x) rather that starting your own development
branch. 3.x isn't not that far from being ready, if we all work on it.

> I prefer 2, because that means that we will have a 2.x for more conservative 
> users, which will automatically work with new chips as they are added to the 
> kernel, and this might save us from having todo a 2.10.6 (2.11.0 is about as 
> much work as 2.10.5 I guess).
>
> Please let me know which one it will be, then I'll start working on the choosen 
> path.

Option 1, definitely.

-- 
Jean Delvare

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