On Mon, 29 Jul 2002 18:46:41 -0400 Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 30, 2002 at 12:09:08AM +0200, Eduard Bloch wrote: > > > #include <hallo.h> > > Matt Zimmerman wrote on Mon Jul 29, 2002 um 09:00:42AM: > > > > > What is the basis for your objection? Are you going to try to stop someone > > > else from doing this development? > > > > Pretty simple. The same reason as for not having XFS in the default > > kernel: > > > > - development stage Yes, but xfs is getting cleaner as time goes by. Development thereof seems to be in capable hands, whose owners have fairly deep understanding of the kernel. > > - not in the kernel Reasons for things not being in the kernel are not always technical. Will you not want grep because it is not in the kernel? (OK, sorry, not the greatest example; point being there are developments that should be looked at; some of those are modules developed in periphery. In this way, changes can be prepared for sooner.) > > - changes lots of stuff in the kernel Sheesh... OF COURSE it does: it is a kernel module. How will you get an external module in without doing so? What does either do other than add themselves to the kernel as a module? Be specific. OK, maybe you're right WRT the -default- debian kernel. > > - not stable or has other nasty bugs Specifics. No fud, please. Please include references and examples. > > - future stable version breaks things Future fud. How would you know? All you can do is guess. The only thing I can grant you here, is we've all seen that happen in the past. > > I know that you like EVMS, and I do too, but it's still beta-ware. You may > > argue that it will be stable to the time when Sarge is ready - but we do > > also release with 2.2.x as default 1.5years after 2.4 release. > > I am in complete agreement that we would not want to include EVMS, XFS or > similar in our default kernel unless (or until) they are part of the > official kernel. Please find the reason for EVMS not being incorporated. Also, is LVM not going to be part of the kernel in the future? I'm not totally sure about this part, but I thought I had read that Linus wants LVM out; note that there have been fairly nasty core-level bugs in LVM in the recent past (the last one I knew of involved main stack overflow causing big filesystem problems: I recall patching to kill that particular bug on my personal machine). >From what I know about LVM and EVMS, the latter's development is being carried out by people who understand the kernel; the former, not so much: some of the LVM developers had a falling out with others; the group who understood kernel issues were harping on technical issues. They got kicked off the mailing list for doing so. Hence, they are left with people who don't understand the kernel quite as much. I propose that we measure the stability of each, and make a decision based on stability, rather than whether or not a certain module passed political muster to be included in the kernel. I further propose that we take looks at these technologies more often, looking at the development status and trying things out. In addition, let's get more people working on debian-installer. Having built it once, I find that process easier than b-f (having also built -that- once as well). Now I need better floppies, so I can try it :) > However, I am willing to do some work to support EVMS in d-i, and to provide > EVMS-enabled installation media for those who are interested in trying it. That's definitely more like it... there are many who would want to try such things. It would also be good to work toward standardizing naming of volumes (err, allowing such naming of volumes to happen in the installer), and allowing the creation of EVMS, LVM, LVM2 (worth a look!) volumes. Current installer does not allow these things; I think work in these areas should begin as quickly as possible. Should the kernel VFS be extended to allow things along these lines? > If I can use this experience to improve volume management support in d-i, > then I would hope that my contributions would be welcome. As far as I'm concerned, such contributions would be very welcome. > - mdz -Jim P.S., I just noticed I'm replying to a 3-week-old message; hope my comments are still appropriate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
