What's wrong with that?
> >
> > biggest problem imo is the reluctance to patch 2.2 up. before you took it
> > for granted that every now and then you'd have to update tools along with
> > the kernel. 2.2 has reversed the trend, and we've got to the situation where
> > the kernel stuff is way out of date compared to the maintainers patches. So
> > when the update finally happens it ends up being a big one, and people get
> > stung.
>
> Which is exactly why it should not be happening as an incremental
> of a stable kernel!
Why not? I think it's fine to expect an upgrade in a userspace tool or
two even when upgrading "stable" versions of code. If there's a
problem that needs to get fixed, fix it. If users are not experienced
enough to compile/install new versions of userspace utilities they
probably shouldn't be mucking around with hand-compiled kernels and
should stick to the binary kernels released by their distribution
vendor.
>
> > I've currently got various nfs, apm and tulip patches to apply when i build
> > a kernel. Thankfully with 2.2.12 i don't have to apply raid anymore. I also
> > had alpha patches to apply before 2.2.11. (but i still had to back out one
> > change...).
> >
> > I also use devfs (but let's please not get into that), and would really love
> > to be able to use LVM on top of RAID, but that needs further patching.. :(.
> > All in all i spend ~30min applying patches and merging rejects when i build
> > a kernel. And most are so long standing that in a lot of cases i know the
> > rejects off by heart.
> >
> > So why not be more adventurous with synching the kernel up. Those who want
> > to be on the edge can update their tools as neccessary, those who want tool
> > stability can track their distributions update instead. That'd be a lot
> > better than the current mess of endless patches to patches to ...
>
> What *would* be better is if people stopped pulling an ISDN, put
> development back in the devlopment kernel and the stable kernel
> went back to getting bug fixes. Right now the "stable" 2.2 seems
> to be getting development ahead of 2.3. This is just silly.
>
> Mike
Well I would agree with you there (but I don't think RAID is "pulling
an ISDN" - to my knowledge the RAID patches have been available for
quite some time.). But, you have to realize that the 2.2 kernel came
out WAY late. It should not have been so long between 2.0 and 2.2. I
think because of that things got out of sync. I don't know if RedHat
made a mistake by including the 0.90 patches in their 2.2.5 kernel or
not, but what were they supposed to do? The old RAID version is
broken. Ask anyone on the linux-raid group (and if you are using RAID
in linux you should really be on that list anyway). I guess RedHat
wanted to provide it's users with a stable RAID along with the stable
kernel. Can't blame them for that! That 0.90 didn't make it into the
base 2.2 is a shame but that's how it went.
I don't consider putting 0.90 into the 2.2 kernel as "development" as
the 0.90 RAID patches were available since October 98!!! Yes, there
have been a bunch of updates since then, with the latest on July 24th,
but the base 0.90 has been available for quite a while. What's in the
2.2.11 kernel? Here's some timestamps for previous versions of RAID:
0.36 July 97!!!
0.41 Sept 97!!!
0.42 Oct 97!!!
0.50 Aug 98!!!
So the earliest version before 0.90 is over a year old. And you
consider 0.90 "development?" 0.90 probably should have been included
in the 2.2 kernel. There may have been known bugs in it when 2.2 was
released, but that's what stable maintenance releases are for (I wasn't
following RAID during the 2.2 release so I don't know if there were
discussions on including 0.90 or not. Those interested can check out
the archives).
If it makes you feel better view the 0.90 RAID code as a bug fix for
the currently broken version of RAID in the kernel.
fwr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/