Re: Does reiserfs really meet the "Linux-2.4.x patch submission policy"?

[torvalds@transmeta.com (Linus Torvalds)]

In article <20010116205558.A1171@sm.luth.se>,
=?us-ascii?Q?Andr=E9?= Dahlqvist  <anedah-9@sm.luth.se> wrote:
>
>Don't get me wrong, I am personally really excited that reiserfs was
>included. I just thought that you basically wanted 2.4.1 to be "boring".

Reiserfs inclusion in 2.4.1 was basically the plan for the very
beginning: it was so widely known that it was even reported in the
press, so I didn't even bother to point out reiserfs as a 2.4.1 patch. 

That said, I wanted to leave the window open for any showstopper bugs,
and have a pure "bug-fixes only" 2.4.1 if needed. I'm actually fairly
happy that there haven't been any really serious reports so far.

Inclusion of reiserfs is not going to add any bugs for the non-reiserfs
case (apart from a stupid merge issue, and now I've watched all the
non-reiserfs diffs with a microscope), so in that sense it's safe.
Peopel who would have used reiserfs anyway would have gotten more
problem reports, so..

If I were you, I'd worry more about the blk-patches from Jens, but
they've been around for a long time, and Alan also put them in his tree. 
Which makes them as safe as any patch we've seen.  So I took the
approach that "we'll obviously have to put this _somewhere_ in 2.4.x". 
But that is, at least to me, a potentially bigger worry than reiserfs. 

(Actually I'm not so much worried that the blk patches themselves would
have bugs, as worried about them showing bugs in block drivers by being
better at merging requests.  Those kinds of bugs we'll have to figure
out during 2.4.x anyway though, but it's a case of a latent bug maybe
showing up more easily under higher load generated by the blk fixes).

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/