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.

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.

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)

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 ;)

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...

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.

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.

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 ;)

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 ;)

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)

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...

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?

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.

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).

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)