From owner-freebsd-hackers Fri Nov 14 16:47:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17082 for hackers-outgoing; Fri, 14 Nov 1997 16:47:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17077 for ; Fri, 14 Nov 1997 16:47:03 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA12978; Fri, 14 Nov 1997 16:47:04 -0800 (PST) To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-reply-to: Your message of "Fri, 14 Nov 1997 15:25:24 PST." <346CDDE4.5656AEC7@whistle.com> Date: Fri, 14 Nov 1997 16:47:04 -0800 Message-ID: <12974.879554824@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ok, then we need another place for 'bleeding edge' then. Your personal tree. That's where truly bleeding edge stuff should go, period (substitute "you" for whomever "you" are - I'm talking generally here). > SMP is anexample of development going on in -current, that > defies both your categories below. If we make -curent into No, actually SMP is a good example as it was done in its own completely different repository for a long time until it was "done" enough to work generally. And it does. I and many other people are running it now and if DEVFS worked half as well as SMP we wouldn't be counting it as an unfinished opus. > -stable, then where does the development go? Development needs > to go somewhere where people can test it out and take it for a > test-drive. I think we have fundamentally different definitions of "test drive." When I think of something worthy of test driving in -current, I think of a situation like "this is done, guys, and I've been testing it for awhile with a small team of private BETA testers. Now I just need a little wider testing to make sure it works as well for everyone else as it does for me and my gang." I don't think "this is something I would like everyone to help me with so that we can finish it and make it work" qualifies. > The reason devfs is in the tree is because it needs people to USE it > to find out what's wrong with it. It was totally broken by a later Julian, I'm sorry, but the DEVFS code has never worked well enough for general use and every time someone has run a /dev mounted with it they've either missed a number of important devices or experienced a system crash in short order. This is code which was integrated prematurely, not code in need of "testing" by the definition I stated earlier. > I'm working offline to replace all that stuff. (The BDE slice code) Good. > > So, what would probably help greatly at this point in proving to the > > skeptics that Julian Elischer, Esq is capable of working within these > > new operating parameters would be an acknowlegement on your part that > > you understand the A/B principles given above and a further > > committment to either removing all traces of DEVFS from the system or > > implementing it entirely to spec sometime within the next 60 days. > > Dont be silly. I'm not being silly. If you don't do precisely as requested above, someone else will be removing DEVFS from the tree in short order. This is not a threat, this is a statement of fact and something we've been discussing in core for awhile now. > It actually works and is in production use in many places. > I don't understand why people consider it to be a non-functional item. > It works on everthing except in some cases of multiple disks. I'm not even going to touch that statement since I think it stands as a perfect example of what I'm talking about, all by itself. Jordan