Re: [STACK] >3k call path in reiserfs

From: Hans Reiser
Date: Fri Jun 11 2004 - 11:41:16 EST


Jörn Engel wrote:

On Thu, 10 June 2004 19:49:04 -0700, Hans Reiser wrote:


Jörn Engel wrote:



It appears to me that most developers agree to the two point above,
but you have some problems with them, at least lately. Am i wrong?


This is all part of what responsible release management is about. I was the junior whiz kid in professional release management teams before starting Namesys. I listened to my elders and learned from them. My standards for professional conduct in this arena are higher than yours as a result of that.

You are a bunch of young kids who lack professional experience in release management. That is ok, but don't get aggressive about it.

I have no desire to pay for your mistakes, and as the official maintainer it is my responsibility to ensure that neither I nor the users pay for the mistakes of those who add bugs to stable branches instead of adding them to the development branches where they belong.



Well, this ain't OpenBSD. They have a strict 6month release schedule,
so your type of development works just fine for them. Linux has
something like a very relaxed 24month+ release "schedule", which is
far too long for some people. As a result, the Linux "stable" kernel
is a lot less stable than the OpenBSD one.

But long release cycles also have their advantages and - most
important - they work with Linus. So effectively, we all have to
accept them and deal with the consequenses. I really understand and
partially share your doubts, but what does it help? ;)

Jörn



Reiser4 is going to obsolete V3 in a few weeks. V3 will be retained for compatibility reasons only, as V4 blows it away in performance.

You are right though that OpenBSD does some things better.

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