Hi all
I'm a little worried about the support for the 2.4.x kernel series. In the
past few releases I've noticed a couple of things that I think are bad for
the kernel.
- Kernel version releases (and -pre releases) do not happen often enough to
keep up with recent hardware
Maybe it's the contrast with the speed of releases on the 2.5.x series, but
while I understand the need for stability on the 2.4.x series, bugfixes and
hardware support should be kept up to date in the stable series as well.
Distributions need this, since every 6 months a new release is made
(mandrake, redhat, suse). If it is not kept up to date, the distros start
using 2.4.x-pre series to provide support for the most recent hardware on
which the new distros are going to be installed.
I'd love to see regular (say once a week) releases -preX releases and no
more than 10 -pre releases before a -rc. No more than 4 -rc's (released no
more than 2 weeks apart) before a new version. Faster full version releases
would also be fine with me.
- Marcello doesn't participate (much) on the kernel list
Again, not really a problem on its own, I'm sure Marcello has a lot of
things to worry about, but somehow it detracts a little from the feeling of
"trust" not to see regular posts form the kernel maintainer about bugs,
patches and how/why patches are applied/ignored.
- Alan Cox seems to provide 90% of the patches to the 2.4.x series
Obviously Alan has responsibilities for redhat, so that explains a lot.
However I get the feeling that patches for 2.4.x are more and more directed
to him rather than Marcello...
My personal interest in this is that my laptop is not yet working 100%...
(see http://margo.student.utwente.nl/simon/ongoing/jade8060.php)
BTW, I've been following the list for at least a year now (mostly via kernel
traffic and kernel releases, but now I'm subscribed)
Cheers everyone and thanks a lot for the work on the kernel!
Simon
> - Kernel version releases (and -pre releases) do not happen often enough to
> keep up with recent hardware
>
> Maybe it's the contrast with the speed of releases on the 2.5.x series, but
> while I understand the need for stability on the 2.4.x series, bugfixes and
> hardware support should be kept up to date in the stable series as well.
> Distributions need this, since every 6 months a new release is made
> (mandrake, redhat, suse). If it is not kept up to date, the distros start
> using 2.4.x-pre series to provide support for the most recent hardware on
> which the new distros are going to be installed.
Distributions typically use modified versions of the standard kernel
anyway. The kernel development schedule has never been based around
the needs of any particular distribution or distributions.
> I'd love to see regular (say once a week) releases -preX releases and no
> more than 10 -pre releases before a -rc. No more than 4 -rc's (released no
> more than 2 weeks apart) before a new version. Faster full version releases
> would also be fine with me.
It doesn't make sense to limit the number of -pre releases and release
candidates - they are needed to make sure, as far as possible, that
the actual release is stable.
> - Marcello doesn't participate (much) on the kernel list
>
> - Alan Cox seems to provide 90% of the patches to the 2.4.x series
>
> However I get the feeling that patches for 2.4.x are more and more directed
> to him rather than Marcello...
I don't see a problem with this, (although we shouldn't just be lazy,
and send all patches to Alan when there are more appropriate people).
Just because somebody is maintaining a subsystem or kernel tree, does
not mean that they have to do the most work, or that nobody else is
expected to edit that code.
> My personal interest in this is that my laptop is not yet working 100%...
> (see http://margo.student.utwente.nl/simon/ongoing/jade8060.php)
I had a quick look, and it looks like it's 95% working, though :-).
John.
On Thu, Feb 20, 2003 at 10:56:58AM +0000, John Bradford wrote:
> > - Kernel version releases (and -pre releases) do not happen often enough to
> > keep up with recent hardware
> >
> Distributions typically use modified versions of the standard kernel
> anyway. The kernel development schedule has never been based around
> the needs of any particular distribution or distributions.
I'm not saying it should, but it would be good from a PR perspective and as
an element in the reliability feeling vector ;-)
> > I'd love to see regular (say once a week) releases -preX releases and no
> > more than 10 -pre releases before a -rc. No more than 4 -rc's (released no
> > more than 2 weeks apart) before a new version. Faster full version releases
> > would also be fine with me.
>
> It doesn't make sense to limit the number of -pre releases and release
> candidates - they are needed to make sure, as far as possible, that
> the actual release is stable.
The number of -pre releases shouldn't be limited for its own sake, but
rather in the process of stabilising the kernel for release. So I mean after
a couple of -pre releases start focussing on debugging and then finish with
a few -rc's before the next cycle starts. That way the diffs between full
versions are smaller and upgrading gets easier.
> > My personal interest in this is that my laptop is not yet working 100%...
> > (see http://margo.student.utwente.nl/simon/ongoing/jade8060.php)
>
> I had a quick look, and it looks like it's 95% working, though :-).
yup, I'm getting there :-) Would be nice to have the smartcard reader
working as well... Some things I can't test because I don't have the
hardware (IEEE1394, wireless lan, irda). power management is still quite
magical to me though ;-)
Cheers
Simon
Hello,
> I'm not saying it should, but it would be good from a PR
> perspective and as
> an element in the reliability feeling vector ;-)
Not sure about it... People like it when a product looks stable,
and having a -blah or -pre and so on once a week doesn't make
me feel I have some stable product...
> The number of -pre releases shouldn't be limited for its own sake, but
> rather in the process of stabilising the kernel for release.
> So I mean after
> a couple of -pre releases start focussing on debugging and
> then finish with
> a few -rc's before the next cycle starts. That way the diffs
> between full
> versions are smaller and upgrading gets easier.
So, the question is to choose between :
- less releases with more changes
or
- more relaseases with less changes
Is that correct ?
Paul
On Thu, Feb 20, 2003 at 02:11:46PM +0100, Paul Rolland wrote:
> Hello,
>
> > I'm not saying it should, but it would be good from a PR
> > perspective and as
> > an element in the reliability feeling vector ;-)
> Not sure about it... People like it when a product looks stable,
> and having a -blah or -pre and so on once a week doesn't make
> me feel I have some stable product...
But that's only because the kernel is in public development, it's not a
black box (which is a Good Thing (tm)). You shouldn't need to run a -pre
kernel release in 99% of all cases, so having them available shouldn't
detract from a feeling of stability (regardless of how often they come)
> > The number of -pre releases shouldn't be limited for its own sake, but
> > rather in the process of stabilising the kernel for release.
> > So I mean after
> > a couple of -pre releases start focussing on debugging and
> > then finish with
> > a few -rc's before the next cycle starts. That way the diffs
> > between full
> > versions are smaller and upgrading gets easier.
> So, the question is to choose between :
> - less releases with more changes
> or
> - more relaseases with less changes
>
> Is that correct ?
I guess so.
There's probably not a "right" way to choose between the two, but I'd prefer
the latter option.
Cheers
Simon
On Thu, 2003-02-20 at 10:24, Simon Oosthoek wrote:
> - Alan Cox seems to provide 90% of the patches to the 2.4.x series
>
> Obviously Alan has responsibilities for redhat, so that explains a lot.
> However I get the feeling that patches for 2.4.x are more and more directed
> to him rather than Marcello...
Seems to be that way.
> My personal interest in this is that my laptop is not yet working 100%...
> (see http://margo.student.utwente.nl/simon/ongoing/jade8060.php)
The ipaq guys I think had some kind of driver for generic MMC cards. SD
cards are full of DRM and off limits to anyone who doesnt wish to sell
their soul