Location of Linux Kernel-2.4.18-nj1 is
http://www.geocities.com/camel_10.geo/linux/patch-2.4.18-nj1.gz
ChangeLog Linux Kernel-2.4.18-nj1
* Merge 2.4.18-pre1
* Fix RadeonFb so it will compile (Nick Kurshev)
* RPM build updated for current RPM (Phillip Dalrmple)
* i810 audio fixed lock up's (Doug Ledford)
* Fixed return of blkgetsize64 (Eric Sandeen)
* Fixed cdrw drive's from hanging on initial INQUIRY
| driver 53c700 Scsi (James Bottomley)
* Fixed Sysrq key's so that you may see the correct output
| (Harald Holzer)
* 2.4.17-10c Reverse VM mapping (Rik van Riel)
* Fixed missing Scsi device ID (Stefan Wieseckel)
> Location of Linux Kernel-2.4.18-nj1
Hi Nathan,
Please don't take it bad, I don't want to flame you nor anybody, but I
think that if everyone publicly announces his own tree with his own set
of changes against the main kernel, many users will be lost quickly.
Once, we had "only" 3 main trees for the stable release :
- Linus' official kernels
- Alan's who did an excellent job at combining a stable core with experimental
drivers
- Andrea's kernel which is more oriented towards big servers and very high
loads.
Now that Alan is working on something else, I can easily understand that
people need a branch like the one he maintained, even if the majority of his
work has been merged into the main tree.
But there is now an -mjc tree, an -nj tree, perhaps others I missed, and many
more not announced here (-wt, I remember of Mathias Andree's -ma for example
who may have been the first one to merge ext3 and reiserfs into a same kernel).
All of them include nearly the same set of fixes that have not yet got into
the official kernel, plus a set of more-or-less stable, more-or-less
interesting features (depending who the targets are). At least, each one
should announce the goal of his kernel, and who it is intended to : developpers,
production users, desktop users, testers, all of them ? With your announce,
nobody even knows if he takes some particular risks using features from your
kernel. Example: I believe that at least Andre Pavenis still has problems with
Doug's i810_audio driver, so this cannot be annouced simply as a "fix" without
a little note.
I sure know it takes a lot of time maintaining a set of patches against a
mainstream kernel, and it even takes more time reading bug reports and
determining what is stable and what isn't. Not to tell about the dozens of
compilations before an announcement (because you compile them, don't you?),
and occasional porting of some fixes to other architectures.
So I really think it would be more productive if people worked around a
smaller set of trees, stopped editing patches by hand again and again to
resolve the same conflicts and tried to be a bit more understandable for
newbies who are a bit lost when they don't know what kernel to try.
Perhaps you could have sent your patches to Mickael Cohen to help him release
an -mjc2 more quickly, like we all did with Alan ? Or perhaps you have a clear
idea in mind about what your kernel tree will be, but in this case, please
elaborate on this a bit more than this simple post, and prepare to cope with
bug reports from people who will trust your tree. This last point may be the
major reason why I chose to keep my kernels for my friends and I...
I hope you didn't take it as an attack, it wasn't really against you, nor to
start a flame war, but just to make people think a bit about something more
constructive.
Regards,
Willy
On Sat, Jan 05, 2002 at 11:52:21AM +0100, Willy Tarreau wrote:
> > Location of Linux Kernel-2.4.18-nj1
>
> Hi Nathan,
>
> Please don't take it bad, I don't want to flame you nor anybody, but I
> think that if everyone publicly announces his own tree with his own set
> of changes against the main kernel, many users will be lost quickly.
>
> Once, we had "only" 3 main trees for the stable release :
> - Linus' official kernels
> - Alan's who did an excellent job at combining a stable core with experimental
> drivers
> - Andrea's kernel which is more oriented towards big servers and very high
> loads.
>
> Now that Alan is working on something else, I can easily understand that
> people need a branch like the one he maintained, even if the majority of his
> work has been merged into the main tree.
I'd actually argue against this. When Alan picked up 2.2.x, there
wasn't someone else doing an -ac'ish 2.2 release as well. Marcelo is
doing 2.4.x now, and seems to be doing a good job of making sure stable
stuff gets in, and other stuff doesn't. The only patches that won't
make it into Marcelos tree in the very-near-term (Which is all I'll
speculate about) are the preempt (and lock-break) patches.
Please people, more trees are not always a better thing when you're all
doing the same thing.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Hello Tom,
> I'd actually argue against this. When Alan picked
> up 2.2.x, there wasn't someone else doing an -ac'ish
> 2.2 release as well.
Right, but at 2.2 times, there were less features and
less users than now. Preemption, PNPBios, Tux,
schedulers, additionnal filesystems are many features
that interest lots of people. Not that Alan did
include
them all either, but at least he gave the opportunity
to test some of them (think about ext3 and pnpbios).
> Marcelo is doing 2.4.x now, and seems to be doing a
> good job of making sure stable stuff gets in, and
> other stuff doesn't. The only patches that won't
> make it into Marcelos tree in the very-near-term
> (Which is all I'll speculate about) are the preempt
> (and lock-break) patches.
I totally agree. And that's why I find it still
acceptable to have one tree (and not 1000) to test
other features such as the ones above, so a large set
of users can test them (eg: filesystems).
> Please people, more trees are not always a better
> thing when you're all doing the same thing.
Perhaps people who have a solid personal tree would
like to continue this discussion off-list and find
an arrangement about a single test tree. Concerning
stable trees, I think that both Marcello's and
Andrea's are rock solid. Othe people may want to use
their distributor's.
I'll stop here to avoid decreasing the s/n ratio too
much. Off-list correspondance OK.
Regards,
Willy
PS: I really like your domain name, it could have been
dedicated to my tree :-)
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Courrier : http://courrier.yahoo.fr
On Sat, 05 Jan 2002, willy tarreau wrote:
> Perhaps people who have a solid personal tree would
> like to continue this discussion off-list and find
> an arrangement about a single test tree. Concerning
> stable trees, I think that both Marcello's and
> Andrea's are rock solid. Othe people may want to use
> their distributor's.
What *I* personally would greatly appreciate: the Big List of Kernel
Patches. It would list a patch, what it does, what version of the kernel
it is against, where it can be found, and maybe where other versions can
be found or conflicts.
This list could e. g. look like (cast into any form you like, an
extensible one is a good idea); I've just picked a random patch that I
use, without any recommendation:
PATCH: Pre-Emptive Kernel
AUTHOR: Robert M. Love
SUMMARY: Makes most parts of the kernel preemptive to reduce latency.
URL: http://www.tech9.net/rml/linux/
PATCHES-STABLE: 2.4.16, 2.4.17 <- only list patches yielding working releases
PATCHES-STABLE-PRE: 2.4.18-pre1
PATCHES-DEVEL: 2.5.1
PATCHES-DEVEL-PRE: 2.5.2-pre1
REQUISITES: -
CONFLICTS: O(1) scheduler
Resembles MAINTAINERS? Rightly so, just more detail given.
That way, we would not need to have so many distinct trees, but this
could easily grow into a patch repository where people could pull their
patches from. I presume that conflicts between patches meant for
inclusion will be worked out; maybe this list should announce
sub-versions of the patches, like Willy mentioned:
PATCH: ReiserFS for ext3-enabled kernels
AUTHOR: Hans Reiser et al.; Matthias Andree et al. (ext3 compatibility)
URL: http://mandree.home.pages.de/kernelpatches/v2.2/v2.2.19/
PATCHES-STABLE: 2.2.19
PATCHES-STABLE-PRE: -
PATCHES-DEVEL: -
PATCHES-DEVEL-PRE: -
REQUISITES: -
CONFLICTS: -
You get the idea. Comments?
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
On Sat, Jan 05, 2002 at 08:41:40PM +0100, willy tarreau wrote:
> Hello Tom,
>
> > I'd actually argue against this. When Alan picked
> > up 2.2.x, there wasn't someone else doing an -ac'ish
> > 2.2 release as well.
>
> Right, but at 2.2 times, there were less features and
> less users than now. Preemption, PNPBios, Tux,
> schedulers, additionnal filesystems are many features
> that interest lots of people. Not that Alan did include
> them all either, but at least he gave the opportunity
> to test some of them (think about ext3 and pnpbios).
>From what I remember, there were lots of other projects going on in 2.2
time, and lots of the stuff in 2.3 (think USB) was done with 2.2.x/2.3.x
compatibility glue. And of all of the things you listed above, they
should all work independantly of eachother too, for the most part.
> > Marcelo is doing 2.4.x now, and seems to be doing a
> > good job of making sure stable stuff gets in, and
> > other stuff doesn't. The only patches that won't
> > make it into Marcelos tree in the very-near-term
> > (Which is all I'll speculate about) are the preempt
> > (and lock-break) patches.
>
> I totally agree. And that's why I find it still
> acceptable to have one tree (and not 1000) to test
> other features such as the ones above, so a large set
> of users can test them (eg: filesystems).
But why do we need yet another tree for this? There already is a large
set of users testing the preemption patches, and I'm not aware of any
new filesystems yet, but I don't see why they'd need another tree
either. A lot of what the -ac tree did was provide maintainers another
person to give their patches to (since sending stuff to Linus is a hit
or miss thing for many people) that tended to have a high rate of
success (or comments) with Linus. Marcelo is very good about taking
patches from maintainers (and telling other people to send stuff to said
maintainer first).
> > Please people, more trees are not always a better
> > thing when you're all doing the same thing.
>
> Perhaps people who have a solid personal tree would
> like to continue this discussion off-list and find
> an arrangement about a single test tree. Concerning
> stable trees, I think that both Marcello's and
> Andrea's are rock solid. Othe people may want to use
> their distributor's.
Again I say, why do we need a 'test' tree? I really don't see more than
one large patch/project/feature getting into a final release, so testing
that project with a bunch of other projects actually invalidates the
testing of it.
> I'll stop here to avoid decreasing the s/n ratio too
> much. Off-list correspondance OK.
I'd really rather not just yet. I'm pretty sure this is all on-topic
still.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Sat, Jan 05, 2002 at 10:06:14PM +0100, Matthias Andree wrote:
> On Sat, 05 Jan 2002, willy tarreau wrote:
>
> > Perhaps people who have a solid personal tree would
> > like to continue this discussion off-list and find
> > an arrangement about a single test tree. Concerning
> > stable trees, I think that both Marcello's and
> > Andrea's are rock solid. Othe people may want to use
> > their distributor's.
>
> What *I* personally would greatly appreciate: the Big List of Kernel
> Patches. It would list a patch, what it does, what version of the kernel
> it is against, where it can be found, and maybe where other versions can
> be found or conflicts.
http://kernelnewbies.org/patches/ is a good starting point. If you like you
can get CVS access from riel and improve the PHP.
regards
john
--
"Unless everyone else on earth is attending meetings I haven't been told
about."
- /. paranoia at its finest
On Sat, Jan 05, 2002 at 11:52:21AM +0100, Willy Tarreau wrote:
> Hi Nathan,
>
> Please don't take it bad, I don't want to flame you nor anybody, but I
> think that if everyone publicly announces his own tree with his own set
> of changes against the main kernel, many users will be lost quickly.
My worry is that l-k will now house discussions of 2.0, 2.2, 2.4,
2.5, aa, dnj, et al...
I care very little for discussion of all the kernel varients other
than those that I am interested in.
In fact, I really could care less about any dicussion other than
2.2 and 2.4. However, I have to wade through all the discussion
of the other versions to get to what I want. Often there is nothing
in emails that idenfity what versions the other is talking about.
And now with the flood of new kernel trees, the info I am
particularly interested in is going to be even further buried.
Since the powers that be are utterly against breaking l-k into
topical subgroups, how about the various "versions" including something
that I can use to identify and toss those messages I am not
interested in.
I'm primarily a 2.4 user, why do I care about all this 2.5 discussion?
--
Brian Litzinger <[email protected]>
Copyright (c) 2002 By Brian Litzinger, All Rights Reserved
> Often there is nothing in emails that idenfity what
> versions the other is talking about.
even more true these days with 2.5. Sometimes, you can
only rely on the poster to guess what version he's
talking about. Eg: at least when I see Linus, Jens or
Dave Jones, I assume it's about 2.5 before reading the
mail.
> how about the various "versions" including something
> that I can use to identify and toss those messages I
> am not interested in.
That's what regular posters tend to do :
"[PATCH-2.4]", "[BUG in 2.2.20]", or "[OT]"...
The problem is more about newcomers who don't know
about these posting rules.
> I'm primarily a 2.4 user, why do I care about all
> this 2.5 discussion?
sometimes, a 2.5 bug/fix may also affect 2.4, and this
is only told in the message body.
Willy
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Courrier : http://courrier.yahoo.fr