remove 2.2 support?

Philip Edelbrock phil at
Wed Jan 15 01:36:18 CET 2003

(Sorry to chime in kinda late on this, but I'm trying to digest it.)

Humm, I guess we are touching on three issues in regard to the CVS, 
2.4.x releases, and 2.5.x kernel sync ups:

- having some support for 2.4.x kernels, at least until 2.6.0 is released.

- submitting and receiving sync patches (Linus') to a rolling 2.5.x base

- continued easy development/maintenance (including alpha and beta 
quality stuff)

We should keep CVS, just for the sake of an already easy, established 
development platform.  I think we agree with that.

I don't like the idea of branching because it means there is more to 
worry about, *but* it may not be avoidable (at least for a while).  
Having 2.5 be HEAD and a secondary branch for 2.4.x kernels (which will 
go dormant eventually) is a good idea.  Is there a reason to branch i2c 
as well, or can we simply freeze the 2.4.x kernel version of it for 
simplicity? (if it helps)

What we are left with is how to deal with alpha or beta stuff which is 
written against HEAD but is not worthy/safe enough to submit in a patch 
to Linus.  It should be obvious and deliberate enough to safely keep 
questionable code in a place (or way?) which won't accidentially make it 
into the kernel before it's time.  In any case, I want to keep it easy, 
still, to have drivers which will be broken at any point to make the 
barrier to entry of new drivers (bus and chip) low.  Does this make sense?

Removing some stuff to make the project easier to maintain is a good 
idea (as we already decided about the 2.2 kernel stuff).  I wonder how 
long we will still need stuff like mkpatch, too?  If we can solve the 
long-term development problems by removing legacy utils, it could be 
helpful to make less to worry about.


Mark Studebaker wrote:

> I think you are right that there is no reason to release before 
> branching.
> We do need to test and then tag before branching.
> I'll try and test your i2c changes soon.
> I think also there is no reason to branch both i2c and sensors
> at the same time. sensors will obviously take longer.
> I suppose we would release 2.5 code as 3.0.0
> and 2.4 code as 2.8.0?
> I read up on CVS branching a little bit. I guess you are propsing
> that 2.5 becomes HEAD and 2.4 becomes something else.
> Then you use -r branchname to pick a branch.
> Phil, really need to hear opinions from you on this.
> mds
> Kyösti Mälkki wrote:
>> On Sun, 12 Jan 2003, Mark Studebaker wrote:
>>> We have a vote from Kyösti for branching.
>>> Albert suggested the same thing to me in an email.
>>> Pavel suggested abandoning CVS and doing everything in Linus' tree.
>>> I'm really reluctant to branch but it may be the only realistic way 
>>> to do it
>>> unless somebody volunteers to do patches manually (and perpetually).
>> There was still a choice of what to branch. Choosing wisely, we can
>> limit commits between branches to one direction.
>> I suggest we have main branch for 2.5 development,
>> - Some day 2.5 results become main anyway.
>> - Patches to 2.4 are not likely to touch kernel interfaces
>>   -> merging 2.4->2.5 painless
>> - Patches to 2.5 are likely to touch kernel interfaces only
>>   -> little to none merges 2.5->2.4
>> I see no reason to release 2.8.0 immediately. Just tag CVS before we
>> branch, then do 2.4<->2.5 cleanup and de release once there is something
>> new to offer.

More information about the lm-sensors mailing list