Re: 2.4.27-12 for Sid
Joey Hess <joeyh@debian.org> wrote:
> [-- text/plain, encoding quoted-printable, charset: us-ascii, 15 lines --]
>
> Horms wrote:
>> Holger kindly reminded me on IRC yesterday that its been
>> a long time since a new 2.4.27 was uploaded into Sarge.
>> He pointed out that there are a number of valuable fixes
>> in SVN.
>
> Is there any reason why you're sticking with 2.4.27+patches rather than
> following the 2.4 series upstream? Seems to this uninformed observer
> like it might be less work to follow upstream since it's limited to
> security fixes, serious bug fixes, and driver backports, assuming
> merging with it isn't too much work.
Well, the main reasons are:
1) The patches are actually coming in at a very slow rate so
keeping 2.4.27 up to date hasn't proved to be a great burden
(though the same would be true of 2.4.32)
2) The merge takes time.
3) Currently maintaining 2.4.27 for sid also maintains it for sarge,
two birds, one stone.
Thats not to say that they are good reasons. But they are the reasons.
To be quite honest, I would be very happy if someone would take over
looking after 2.4. And update it to 2.4.32 and the new packaging
infastructure that is now used for linux-2.6 in sid/etch.
At the time that I started working on 2.4 packaging, 2.4 was slated as a
viable kernel for a significant userbase for sarge. Looking forward, it
is my belif that by the time we hit etch, 2.4 will only be for niche
users, older hardware and arches that don't have 2.6. I think those
users are very worthy reasons to keep 2.4, at least on arches that need
it. But I'm finding it hard to get excited about doing it myself.
Holger mentioned he would be interested in looking into it. He also
mentioned that his coding skills are a little weak. Personally I don't
think that is mich of a problem. What is needed is someone who is
patient, can work with people to find answers, can do simple merging of
patches and in short, manage package releases. In my time working on the
kernel team I have spend much, much, much more time doing those things
than the occasional like of code I write as a bugfix.
--
Horms
Reply to: