remove 2.2 support?
phil at netroedge.com
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
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
> 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.
> 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