Recent Features
| ||||||||||||||||
Re: [STACK] >3k call path in reiserfs
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? > >Jörn > > I have a concept of stable version and development version. V3 is the stable release branch, and should not be disturbed except for bug fixes. V4 is where all new features go. In not very long, V4 will enter code freeze, and we will open a V5 branch where all new features will go. Filesystem users want conservative release management. This is not gimp, this is a filesystem. It must be a zero defect product or it is useless. 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. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ (Log in to post comments)
Re: [STACK] >3k call path in reiserfs Posted Jun 17, 2004 14:28 UTC (Thu) by khim (subscriber, #9252) [Link] V3 should remain unchanged. If Linux wants ReiserFS AND 4K stacks, they're going to have to wait for V4. Oh, yeah. It does not matter of ReiserFS 3.x on 2.6.x will eat your data for breakfast (it did for me) - it's stable branch and it should never be changed even if it does not work anymore. Really great way to get new customers for paying support... If they'll not switch over to xfs (as I'm thinking to do). It's big and ugly and not as elegant but xfs maintainers do make changes needed to make it work again when kernel internals changes not suggest to switch to "latest and greatest" as the only way to get it working on last version of kernel...
Re: [STACK] >3k call path in reiserfs Posted Jun 17, 2004 17:23 UTC (Thu) by melauer (guest, #2438) [Link] >Oh, yeah. It does not matter of ReiserFS 3.x on 2.6.x will eat your data for>breakfast (it did for me) - it's stable branch and it should never be >changed even if it does not work anymore. Really great way to get new >customers for paying support... The issue is more complex than that. First, if 4K stacks are optional, then the solution to this problem is simple: make it impossible to select 4K stacks and ReiserFS v.3 in the kernel config. That's the simplest approach and should be acceptable to everyone. Just make those two incompatable chunks of code mutually exclusive and leave it at that: you get one or the other, period. Now, as for the actual complaint, the 4K stack thing was added to a supposedly stable kernel. I'm guessing that Hans Reiser's comment was not so much about never changing stable code (I bet ReiserFS changed at least a little between 2.4.x and 2.6.x, and you always have to fix bugs) as about not making major design changes to supposedly stable code... like the Linux development crew did when they added 4K stacks. He has a point there! Having said that, if the current ReiserFS code does not work with the current kernel, that should be considered a bug in the ReiserFS code. It shouldn't matter whether the problem is a major change to the kernel or something smaller like a redefined constant. If ReiserFS v.3 doesn't work in version X and all later versions of the kernel, then it's the ReiserFS code for Linux (does it work with any other OSes?) which should change. The Linux ReiserFS implementation is a derivative of the Linux kernel, not the other way around, so guess whose changes get priority? Now, Hans Reiser has every right not to change the v.3 code if he wishes. Nobody is ever forced to contribute anything to the kernel for any reason, so v.3 doesn't have to change. Considering that v.4 is "almost ready", it makes a lot of sense that v.4 is the current focus of Mr. Reiser's development efforts. He just shouldn't be surprised if v.3 gets marked "depreciated" or even removed from the kernel sooner than expected (e.g. before v.4 is ready). One more note: perhaps someone else would be interested in taking v.3 and finding a way to get these things working together? We are talking about open source code here, right? I wouldn't be surprised if some major distro were thinking about this right now (I notice that Mandrake uses ReiserFS by default and has released a 2.6.7-rc3 kernel...). I suspect, though, that they'd opt to remove the 4K stacks from their kernels rather than ReiserFS. 4K stacks can cause other problems, and I assume that nobody wants barely-tested, application-breaking code in their distro's kernel!
Re: [STACK] >3k call path in reiserfs Posted Jun 19, 2004 19:19 UTC (Sat) by khim (subscriber, #9252) [Link] Someone tried to do just that. Without trying to convince Hans to do it himself (or with NameSys developers help). That is what started the whole debate.
|
||||||||||||||||