mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grzegorz Kulewski <kangur@polcom.net>
To: Diego Calleja <diegocg@gmail.com>
Cc: arjan@infradead.org, caleb@calebgray.com, linux-kernel@vger.kernel.org
Subject: Re: Reiser4 Inclusion
Date: Mon, 17 Jul 2006 16:31:06 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.63.0607171611080.10427@alpha.polcom.net> (raw)
In-Reply-To: <20060717160618.013ea282.diegocg@gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3511 bytes --]

On Mon, 17 Jul 2006, Diego Calleja wrote:
> El Mon, 17 Jul 2006 13:48:02 +0200 (CEST),
> Grzegorz Kulewski <kangur@polcom.net> escribió:
>> If someone thinks that Reiser4 is too unstable or evil he can set it to N
>> and be happy. And if Reiser4 will be abandoned by Namesys and not fixed
>
> http://wiki.kernelnewbies.org/WhyReiser4IsNotIn

I already read it when it was posted first. I am reading LKML and 
reiserfs-list for several years and I already read all that arguments, 
flames and so on that were ever pointed here. I think I have enough.

But if we are there:

""But just include it as experimental code regardless of everything, 
reiser programmers will fix all the problems eventually!"

Well, no and yes. As said, nobody expects reiser 4 to be bug-free, but 
there're some important issues that need to be fixed, the problems is 
that reiser 4 is still working in the important ones. Some of the issues 
fixed in the past included severe design issues, BTW. Others are about 
being well integrated with Linux: duplication of kernel's own 
functionality for no reason, etc. Every piece of code submitted needs to 
have some quality - requesting developers to fix severe issues before 
getting it into the main tree helps to have better code. If you ask 
people people to fix those issues "in the future", they'll be lazy and 
there'll be critical issues around all the time - this has happened in 
Linux in the past. Quality is important, specially under a stable 
development phase. Linux is already being critized a lot for merging new 
features during this stable phase - that criticism happens with the 
current quality control. Imagine what would happen if linux started to 
merge things without caring a bit about what gets merged. Also, consider 
what Reiser 4 is. It's a filesystem, once it gets included in the kernel 
many people WILL use it and will DEPEND on it (your disk format is 
reiser4): Linux needs to ensure that things don't blow up everything."

Why do some people think that users are not already depending on it? They 
are. I don't know how much but I am willing to bet that at least 100 
people. I think that there are some drivers in the kernel that have 
smaller user base.

Keeping Reiser4 out of kernel is even worse (for those users, other users 
that could test this filesystem, for Reiser4 developers and whole 
comunity) than accepting it for a try period with a big fat warning that 
it my be removed if Namesys abandons futher fixing of it (after some time 
to let user migrate).

And any arguments like "if Reiser4 is not in the kernel then people will 
not use and depend on it" are fundamentally flawed IMHO. Everything bad 
that could happen with Reiser4 in the kernel can happen with Reiser4 out 
of it.

It may look like some kernel developers are trying hard not to take 
responsibility for Reiser4 saying that there is very huge difference 
between selecting highly experimental kernel feature that is marked so and 
patching the kernel with it. Sorry but I think there is very little 
difference. And that little difference is only hurting users that want to 
try and test something new.


Thanks,

Grzegorz Kulewski


PS. I really don't want to begin World War 4 about Reiser4. I just think 
that curious people asking from time to time about _current_ Reiser4 
status should not be treated bad because that could make them stop 
testing and giving back to the open source projects.

  reply	other threads:[~2006-07-17 15:09 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-17  3:02 Caleb Gray
2006-07-17  9:25 ` Arjan van de Ven
2006-07-17 11:48   ` Grzegorz Kulewski
2006-07-17 11:57     ` Alexander Gran
2006-07-17 14:06     ` Diego Calleja
2006-07-17 14:31       ` Grzegorz Kulewski [this message]
2006-07-17 15:51         ` Matthias Andree
2006-07-18  7:59           ` Jan Engelhardt
2006-07-18 20:47             ` Matthias Andree
2006-07-19  1:19               ` Joshua Hudson
2006-07-19  9:27               ` Tilman Schmidt
2006-07-19 11:00                 ` Krzysztof Halasa
2006-07-19 11:03                 ` Pekka Enberg
2006-07-19 15:32                   ` Tilman Schmidt
2006-07-19 19:04                     ` Valdis.Kletnieks
2006-07-19 19:12                       ` Tilman Schmidt
2006-07-19 20:09                         ` Valdis.Kletnieks
2006-07-19 22:36                           ` Tilman Schmidt
2006-07-19 20:29                       ` Jeff V. Merkey
2006-07-19 22:01                         ` Matthias Andree
2006-07-19 22:34                     ` Helge Hafting
2006-07-17 15:52         ` gmu 2k6
2006-07-17 15:57           ` Alexander Gran
2006-07-17 19:01         ` Horst von Brand
2006-07-17 15:13     ` Jeff Anderson-Lee
2006-07-17 15:56       ` Matthias Andree
2006-07-17 20:48       ` Erik Mouw
2006-07-18  0:49         ` Jeff Dike
2006-07-18 11:43           ` Christoph Hellwig
2006-07-17  9:44 ` Patrick McFarland
2006-07-17 11:07 ` Diego Calleja
2006-07-17 14:38 ` Alex Riesen
2006-07-17 18:05 ` Valdis.Kletnieks
2006-07-18 23:10   ` Nix
2006-07-19  6:56 ` Reiser4 ACLs Marc Perkel
2006-07-19 15:03   ` Jan Engelhardt
2006-07-17 22:34 Reiser4 Inclusion linux
     [not found] <06Jul25.011533edt.35900@gpu.utcc.utoronto.ca>
2006-07-30 22:02 ` Tilman Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.63.0607171611080.10427@alpha.polcom.net \
    --to=kangur@polcom.net \
    --cc=arjan@infradead.org \
    --cc=caleb@calebgray.com \
    --cc=diegocg@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®