Kernel Traffic #144 For 3 Dec 2001

There were 624 different contributors. 296 posted more than once. 244 posted last week too.

Linus Torvalds announced 2.4.15-pre9, and added, "I think I'm ready to hand this over to Marcelo." Anuradha Ratnaweera asked if Linus would first please "include Tim Schmielau's patch to handle uptime larger than 497 days? It is a cool feature we always liked to have." But Tim Schmielau replied, "Seeing the differences between pre-patches getting smaller and smaller, I guess I finished the patch just too late in the release cycle. I will keep an eye on it and eventually resubmit it to Marcelo when it needs rediffing." And Linus also replied to Anuradha, saying:

Quite frankly, right now I'm in "handle only bugs that can crash the system mode". Anything that takes 497 days to see is fairly low on my priority list. My highest priority, in fact, is to get 2.4.15 out without any embarrassment.

Because it's not as if time stops when Marcelo takes over. I've suggested to him that he wait for a while just to see what the real problem spots are, but he'll have a full-time job integrating patches.

Note that I'll probably do the same thing: when I release 2.4.15, I'll at the same time release a 2.5.0 that is identical except for version number (that makes synchronization easier later on). And I'll probably _not_ start accepting all the big waiting patches immediately, I'd rather wait for at least a week or two to see that there aren't any other issues.

It's much easier doing some of the IO patches in particular knowing that the base you start out from is stable.

Rob Radez hadn't seen an announcement for 2.4.15 from Linus Torvalds, and Frank Davis added, "Nor did I see an official announcement of Linux 2.5.0 from Linus on lkml. :)" And Pozsar Balazs said with a snicker, "Well, real men just upload their stuff and let the world announce it :)))"

Tim Tassonis was puzzled by the version number of 2.4.15: officially, the number was, "2.4.15-greased-turkey". Jeff Garzik said, "Thanksgiving holiday in America... maybe Linus is giving thanks that he can turn 2.4 over to Marcelo now :)" And Linus Torvalds also answered Tim:

It'sa worthy follow-up to the 2.2.x "greased weasel" releases, but as yesterday was Thanksgiving here in the US, and a lot of turkeys offered their lives in celebration of the new 2.5.0 tree, the 2.4.x series got christened a "greased turkey" instead of a weasel.

It may not have quite the same connotations of slippery speed as the weasel, but then some people said the same thing about the penguin too.

Oliver Xymoron replied that, as a vegetarian, he'd been forced to patch the kernel version to be "2.4.15-greased-tofurkey" before it would compile; and Jamie Lokier added, "I've had better luck with 2.4.15-tasteful-salad."

So here it goes 2.4.16-pre1. Obviously the most important fix is the iput() one, which probably fixes the filesystem corruption problem people have been seeing.

Please, people who have been experiencing the fs corruption problems test this and tell me its now working so I can release a final 2.4.16 ASAP.

Correctly sync inodes in iput() (Alexander Viro)
Make pagecache readahead size tunable via /proc (was in -ac tree)
Fix PPC kernel compilation problems (Paul Mackerras)

He replied to himself a minute later, having forgotten to include the URL, which he now added: ftp.xx.kernel.org/pub/linux/kernel/people/marcelo/2.4/testing/. Phil Sorber replied that he didn't see these announced on the front page of http://kernel.org/. Marcelo said he thought H. Peter Anvin would attend to that soon enough, as H. Peter was the server maintainer. H. Peter also replied to Phil, saying:

let me vent here for a moment...

I WOULD BE BLOODY GRATEFUL IF SOMEONE WOULD ACTUALLY TELL ME THESE THINGS AHEAD OF TIME FOR A BLOODY CHANGE!!!!!!!!!!!!!!!!!!!!!!!!

Every time something changes, something like 200 lusers write to me to bitch & whine, and I have to do script maintenance as soon as possible, despite anything else I may have wanted to do. I am getting rather sick and tired of having to second-guess the kernel maintainers, and I would really like to get just a bit of consideration in that manner.

I also decided that the suggestion to move the "testing" subdirectory down to below the kernel that the directory is for is a good idea.

So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the old kernel/testing directory basically orphaned.

Marcelo could either take over the old directory (which will make his pre-patches show up on kernel.org automatically), or preferably just do the same thing, and make the v2.4 test patches in v2.4/testing (which will also require support from the site admin, who is probably overworked as-is with the RAID failures ;)

Alan Cox replied, "I'll start using v2.2/testing if I remember when I finall get around to 2.2.21pre1."

H. Peter asked Alan to let him know when Alan went ahead with that; and added elsewhere:

I like this idea much better than Marcelo's idea, which requires yet a whole slew of ad hoc knowledge in the scripts -- there is just way too much of that already. I'll try to implement this.

To summarize:

I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in v2.4/testing, and nothing else...

(He hadn't been aware of Alan's intention to use the same method for 2.2 when he posted)

There was some suggestion that 2.0 would also benefit from this treatment, and David Weinehall said at one point, "Well, if people want me to, I can put my prepatches in v2.0/testing." H. Peter was happy.

Elsewhere, in a completely different subthread, there was some discussion about Linus' abilities as a maintainer, the way kernel releases should be handled, and the overall direction and future of the Linux kernel as a whole. Stephan von Krawczyn felt that the problems arose from releasing official versions too soon, resulting things like the 2.4.15 fiasco. But Linus replied:

Actually, I think that is just the _symptom_ of the basic issue: I do not like being a maintainer.

Let's face it, we had similar problems in 2.2.x, for all the same reasons: I'm simply not a good maintainer, because I'm too impatient and get too bored with it.

The fact that I've held on to 2.4.x for too long, mostly due to the VM problems, really doesn't help. That just makes me _less_ likely to be careful. Especially when the last known VM problem was fixed (ie the Oracle highmem deadlock), I had a very strong urge to just "get the d*mn thing out to Marcelo".

I'm much happier doing development, and what I'm best at for Linux is at doing the "hard decisions" - and not necessarily because of technical reasons, but simply because I _can_ make them without too many people grumbling. An example of this is to do the VM reorg in the first place, something that at the time a lot of people disagreed with.

But I'm not a good, careful, maintainer. I never claim to be.

I bet you'll see better, more consistent quality from Marcelo.

Patrick McFarland suggested (which resulted in a kind of mini-flamewar) that Linus stop maintaining any kernel, stable or development. In the course of discussion, several folks accused him of being a troll. He said, "Im probably maybe one of 10 people on this whole planet that would like to see the kernel become more than it is, and would actually help doing it. Obviously, the whole damn community is having problems with me disagreeing with it, so screw it. You guys blew it." At one point Rik van Riel said in reply:

No. People think you're a troll because all you've done up till now is shout around some generic handwaving about how other people should do stuff better.

Now if you showed us some of your work (patches, documentation, tracing down bugs, etc...) you could convince us you're serious about helping out improving the kernel.

Patrick replied that he might have some MIDI-related code (not necessarily kernel-related) in about a month or so.

Elsewhere, there were more peaceful reactions to Linus' statements. Mike Fedyk said:

You admit that you do not like to maintain. We have seen that, and unfortunately for 2.4 it is true.

Personally, I think that 2.4 was released too early. It was when the Internet hype was going full force, and nobody (including myself) could be faulted for getting swept up in the wave that it was.

I'd like to suggest two possibilities.

1) Develop 2.5 until it is ready to be 2.6 and immediately give it over to a maintainer, and start 2.7.

2) Develop 2.5 until it has the features you want to go into 2.6, and give it over to the future 2.6 maintainer to stabalize and release it. (there would be two develoment kernel at the same time for a short period with this)

With both you would get to do what you like and won't get bored with, and let people share their latest code for many to see.

Linus, can you say if you plan to do anything like this0?

That's not the problem, I think.

2.4.0 was appropriate for the time. The problem with _any_ big release is that the people you _really_ want to test it won't test it until it is stable, and you cannot make it stable before you have lots of testers. A basic chicken-and-egg problem, in short.

You find the same thing (to a smaller degree) with the pre-patches, where a lot more people end up testing the non-pre-patches, and inevitably there are more percieved problems with the "real" version than with the pre-patch. Just statistically you should realize that that is not actually true ;)

And to the suggestion of forking the new development series immediately upon the creation of each stable series, Linus went on:

I'd love to do that, but it doesn't really work very well. Simply because whenever the "stable" fork happens, there are going to be issues that the bleeding-edge guard didn't notice, or didn't realize how they bite people in the real world.

So I could throw a 2.6 directly over the fence, and start a 2.7 series, but that would have two really killer problems

(a) I really don't like giving something bad to whoever gets to be maintainer of the stable kernel. It just doesn't work that way: whoever would be willing to maintain such a stable kernel would be a real sucker and a glutton for punishment.

(b) Even if I found a glutton for punishment that was intelligent enough in other ways to be a good maintainer, the _development_ tree too needs to start off from a "known reasonably good" point. It doesn't have to be perfect, but it needs to be _known_.

For good of for bad, we actually have that now with 2.4.x - the system does look fairly stable, with just some silly problems that have known solutions and aren't a major pain to handle. So the 2.5.x release is off to a good start, which it simply wouldn't have had if I had just cut over from 2.4.0.

The _real_ solution is to make fewer fundamental changes between stable kernels, and that's a real solution that I expect to become more and more realistic as the kernel stabilizes. I already expect 2.5 to have a _lot_ less fundamental changes than the 2.3.x tree ever had - the SMP scaliability efforts and page-cachification between 2.2.x and 2.4.x is really quite a big change.

But you also have to realize that "fewer fundamental changes" is a mark of a system that isn't evolving as quickly, and that is reaching middle age. We are probably not quite there yet ;)

Rik came out in strong support of Linus' proposed solution of making fewer changes between stable series, and H. Peter added, "I would REALLY like to see this policy. I have been harping on this for some time now -- we have been having 2-3 times too long cycles between stable kernels, which results in an unacceptable level of pressure to "get your features in" instead of the proper answer "you missed the boat, wait for the next one.""

David Relson was upset by the fact that the stable series had not been very stable of late, and that several official releases had been seriously broken. He offered a suggestion, "When the kernel maintainer, now Marcelo for 2.4, is ready to release the next kernel, for example 2.4.16, I suggest he switch from "pre?" to "-rc1" (as in release candidate). A day or two with -rc1 will quickly show if it has a show stopper. If so, then the minor fixes (and nothing else) go into -rc2. A day or two ..., and either -rc3 appears or we have a stable release and 2.4.16 is ready to be released." Bill Davidsen replied, "I wish you luck. About 18 months ago I offered to set up a testing group to take kernel source before it with up for ftp and to compile it on various x86, SPARC{32,64}, and ALPHA machines to be sure it would at least compile. I was told with varying degrees of rudeness that it would delay the releases (that is a GOOD thing in stable kernels), and that I should avoid the 2.4 series and use the "stable" 2.2 kernsls (2.4 IS a stable kernel of course, although you would never gues it)."

Dan Kegel applauded David's suggestion, and also suggested running releases past the Open Source Development Lab folks prior to each release candidate. Nathan Dabney from that group, replied:

We will be running all the available tests (until that list gets too large to be possible) on each kernel the morning after it's released. That's including pre/test/flyingmonkey/whatever. The test requests after a kernel release are currently automatic.

The regression tests we have planned are the majority of the tests available under the Linux Test Project (sourceforge:LTP). We have not however finished setting these up for automation.

Marcelo is also already working with the lab on non-stp related projects.

QA on the Linux Kernel will happen. However just like everything else in the Linux world, it won't be what you are used to. (read: automatic bug submissions to the LK list will NOT happen.)

One potential issue for waiting for these tests to finish before moving on to the next release is the fact that while all the tests are /requested/ the morning after a kernel hits kernel.org, they may not finish for days. This is because of other tests in the queues from developers or tests that take longer than a single day to complete. My thoughts on this tend towards having a short set of tests that can be considered a "smoke test" on the kernel to verify a short list of basic QA items before the major tests are ordered against a kernel. This short list would catch most compile/boot issues as well as a limited range of driver problems and a decent number of kernel component performance areas. I see the potential to have the STP going in the background from the development effort and only becoming visible to the LK list when we find problems or other things worth commenting on. I don't see a benefit for the development effort to be driven or controlled by anything the QA process does or doesn't do.

It's a constant game of catch up and verification. But at least the tools are getting better.

Due to the corruption problems on 2.4.15, I'm releasing 2.4.16.

Changelog:

final:

Fix 8139too oops (Philipp Matthias Hahn)

pre1:

Correctly sync inodes in iput() (Alexander Viro)
Make pagecache readahead size tunable via /proc (was in -ac tree)
Fix PPC kernel compilation problems (Paul Mackerras)

Dominik Kubla gave a cheer, but Anuradha Ratnaweera suggested that Marcelo should, as a policy, have the final release be identical to the most recent pre-release. Later in the sub-thread, Helge Hafting replied:

A "policy" is a simplification that isn't needed.

This fix could trivially be proved not to make things worse, so no reason at all to omit it. Policies, rules-of-thumb etc. is for management and others without detail knowledge. Those who know better shouldn't be limited by such rules. And they aren't. :-)

Of course it is possible to write down a detailed policy that even expert coders could agree to - but why bother? You wouldn't get it into a few lines...

Alan Cox also said in response to Anuradha, that such niceties were not really necessary "When the patch is totally obvious and there is a need to get a release out." And Rik van Riel also said to Anuradha, "This 8139too fix is ONE LINE, in a self-contained piece of code." Anuradha said that it would still be best to avoid ambiguous situations by implementing a clear policy, but H. Peter Anvin said, "Sorry, but you have just crossed the line of what is reasonable to demand of other people. If you don't trust the maintainers and want to maintain such a policy, fork the kernel and start maintaining it yourself." And Andreas Jaeger put in:

It's Marcelo deciding what it's ok and what not. He's the one responsible for it. If you like to give him a friendly advise - fine with me but I don't think you've got the right to *define* what's ok and what not for Marcelo.

I've got the impression from these threads about maintaince on lkml that a number of people try to force something on Marcelo without giving him a chance to find his own way of doing it. I trust Marcelo that he'll do the right thing.

Could we get back to coding and testing?

Anuradha replied that he also trusted Marcelo, but that he'd just been discussing his own ideas about things.

Marcelo also replied to Anuradha's initial comment, saying that the fix was really very small, and obviously correct; and Anuradha agreed.

Olaf Hering posted an 802 patch against 2.4 to the list, ccing Linus Torvalds and Marcelo Tosatti. Marcelo replied, "Let the correction come to me through the 802 maintainer, please."

Technically there is no such person currently. At best it comes under "networking" and that I guess would be me.

The person who originally wrote this 802 stuff is not active anymore and he is only mentioned in the credits.

Olaf then submitted the patch to David, and they and others went on to discuss it.

David Relson thanked Marcelo Tosatti for taking over 2.4 maintenance, and for putting out 2.4.16; he asked, "Over the last few days, there have been lots of messages regarding "Kernel Release" and "-preX vs. -rcX". You, as the official maintainer of kernel 2.4 are the person who actually creates the release policy and makes it happen. Would you care to share your thoughts on this matter?" Marcelo replied:

Sorry for not being able to discuss this issues... Its just that I'm too busy doing the maintenance and other stuff at Conectiva at the same time (people are flooding me with patches, btw, please stop for a while).

Daniel Quinlan suggested me to release a "pre-final" release before the real final one (which would catch most "stupid" bugs), and I think thats a nice way of solving the problem.

I'll _probably_ do that --- not sure yet, though.

Aren't all the -pre's pre-finals? And what if there is a big bug found in the -final, it will obviously be followed up with a -final-final?

I like the ISC's release methods. The do -rc's (-pre's would be fine for the kernel as it is already established), each -rc fixes problems found with the previous. When an -rc has been out long enough with no more bug reports they release that code, WITHOUT changes.

Just the -pre-final is a -pre-final. :)

-pre-final basically means that this is the "candidate" release for the final.

I could call it "candidate" or whatever (I don't really care about the name).

H. Peter Anvin remarked, "if you settle on a naming scheme, *please* let me know ahead of time so I can update the scripts to track it, rather than finding out by having hundreds of complaints in my mailbox..."

David Weinehall explained his own system, "I for one used the -pre and -pre-final naming for the v2.0.39-series, and I'll probably use the same naming for the final pre-patch of v2.0.40, _unless_ there's some sort of agreement on another naming scheme. I'd be perfectly content with using the -rc naming for the final instead. The important thing is not the naming itself, but consistency between the different kernel-trees." H. Peter replied, "Consistency is a Very Good Thing[TM] (says the one who tries to teach scripts to understand the naming.) The advantage with the -rc naming is that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, -pre-final-really-i-mean-it-this-time phenomenon when the release candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no shame in needing more than one release candidate." Marcelo replied, "Agreed. I stick with the -rc naming convention for 2.4+..." H. Peter replied, "I have updated the kernel.org scripts to recognize the -rc naming convention. Any -rc patch found is assumed to be newer than any -pre patch found. I will try to add tracking of the v2.0 and v2.2 trees sometime later this week." And David Weinehall said he'd use the same scheme for 2.0.

Oliver Xymoron asked if anyone knew of a tool to "put a SCSI disk/driver through its paces" , for use in regression testing. Marcelo Tosatti replied, "Cerberus (stress tool, you can probably find it at freshmeat.net) you can has a SCSI burn test..." Oliver said he'd look into that. Andre Hedrick also replied to Oliver's initial post, saying, "One day I will get around to fixing SCSI to have a low-level diagnostic entry point for a test suite, but not time right now ... sorry." But Oliver replied, "I think the sg interface is actually sufficient for my purposes."

Here comes another one. Unless I receive some more patches, the next patch will be the first release-candidate for v2.0.40

2.0.40pre3

Fix typo in sched.c this time for real; I applied this patch to the wrong kernel-tree last time, hence the reject (Tim Sutherland)
IDE probe patch for some ATAPI drives (Geert Van der Plas)

Stefan Smietanowski (possibly doing some mail-parsing scripting), noticed that David gave the version number as "2.0.40-pre3" in the Subject: line, but "2.0.40pre3" in the body of his message. Stefan was under the impression that David had recently agreed to use the dashed form typically. David replied, "I use it in the Makefile EXTRAVERSION." Stefan asked if there was a reason not to use it everywhere, and David replied, "No, more of a thinko :-)" End of thread.

Marcelo Tosatti announced 2.4.17-pre1. Andrey Nekrasov noticed that the patch failed to update the version number. Marcelo replied, "Yes, I forgot to do that in this release, sorry. Hope it never happens again." Tommy Reynolds replied, "It's OK to make mistakes, as long as they're new ones ;-)"

Elsewhere, Mike Fedyk asked Marcelo, "Any chance you'll merge Robert's netdev-random uniformity cleanup patch with the default to "no"?" Ken Brownfield seconded this proposal, and Robert Love gave a link to the patch. Marcelo said to Mike, "Not sure. Have to read the patch..." End of thread.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	21 Nov 2001 - 26 Nov 2001	(20 posts)	Gearing Up For 2.5 And Handoff To Marcelo
2.	23 Nov 2001	(3 posts)	2.5 Starts Up
3.	23 Nov 2001	(6 posts)	2.4 Hand-Off To Marcelo
4.	24 Nov 2001 - 27 Nov 2001	(105 posts)	Marcelo Takes Over 2.4
5.	24 Nov 2001 - 28 Nov 2001	(35 posts)	Ensuring Stability Of The Stable Series
6.	26 Nov 2001 - 29 Nov 2001	(20 posts)	Suggestions For Marcelo
7.	26 Nov 2001	(15 posts)	Brief Discussion Of Patch Submission Policies For 2.4
8.	26 Nov 2001 - 28 Nov 2001	(47 posts)	2.4 Release Policies
9.	26 Nov 2001	(5 posts)	Tool For SCSI Driver Regression Testing
10.	26 Nov 2001	(5 posts)	Preparing For 2.0.40
11.	28 Nov 2001 - 29 Nov 2001	(13 posts)	2.4 Handoff: The Saga Continues

Kernel Traffic #144 For 3 Dec 2001

By Zack Brown