Date: Fri, 14 Nov 1997 15:25:24 -0800 From: Julian Elischer <julian@whistle.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch Message-ID: <346CDDE4.5656AEC7@whistle.com> References: <9942.879515612@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard wrote: > > > > However, like all projects, we've also matured over the last 4+ years > and with that maturity has come a greater degree of conservatism in > how we do development and in what we expect from any contributor who > seeks to take on a fairly major chunk of development. What might have > been considered reasonably acceptable development practice 4 or even 2 > years ago simply won't fly now that we have a much larger user base > and are under considerable pressure to produce a professional quality > operating system which sets itself well apart from our "competition" > in this arena. ok, then we need another place for 'bleeding edge' then. SMP is anexample of development going on in -current, that defies both your categories below. If we make -curent into -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. > > This means that any work started in the tree needs to be taken to > completion regardless of the degree of participation by others, > and anything you "sign up for" needs to be something which: > > A) You are capable of completing by yourself, any additional > help being in the "nice to have" category but not strictly > necessary to the project since additional volunteer help > simply cannot be counted on as any kind of given. > > B) Something which *is* completed and in a timely fashion, not > simply left as an "exercise to the reader" as it were. > > I don't mean to speak for Soren, but I do believe that he brought up > DEVFS more as an example of something which violated both A and B than > as an attempt to twist your tail and I can speak without fear of > contradiction when I say that it would simply not be possible for you > to introduce such an unfinished work in today's FreeBSD. Yours is > also hardly the only example of this, others being the aborted ISDN > project (which I brought in, to my later embarassment) or Garrett's > devconf stuff which never fulfulled its promise and was later yanked > out to general bitterness and mutual finger-pointing. 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 development.. BDE's slice code. I'm working offline to replace all that stuff. (The BDE slice code) and till that's done devfs is being static but really there is work going on elsewhere. > > We obviously don't want a repeat of those sorts of situations again > and I think that folks have reasonable grounds to worry about *anyone* > who has been responsible for such half-baked assaults on the tree in > the past. It doesn't mean that said person will be judged unfit for > all time, simply that they will have to work just a bit harder in > proving to a skeptical audience that they've fully grasped these new > operating principles and *will* finish anything they start, whether or > not anyone else comes forward to help them with the burden. It's > simply the only way to do things now if we want to avoid a tree full > of good intentions but non-working code. what else have I done that is 'non working?' The boot floppy creation code has worked after every time I've updated it, but you've always been to busy to cut-over to it, so it always gets out of date. Despite the fact that people are always wanting to be able to make boot disks, and that the only way the existing code allows this is in a 'make release' and the other code only needs a 'make world' which is much more acceptable.. So I am interested in your definition of 'responsible for such half-baked assaults' most of the things I have added have been compete working items. > > 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. > > If it also seems like I'm unfairly singling out DEVFS among your other > notable accompishments (and I, for one, rather *like* the divert > socket mechanism - well done, Whistle) then please understand that I'm > underscoring it for the simple reason that it's your current > unfinished opus and something which stands in the way of your > "rehabilition", so to speak. It's also something which simply needs > to either be finished or yanked out, like the other examples I listed > above, and if you're keen to work with us then this is obviously the > first item on the worksheet. 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. Of course that doesn't mean that ther isnt stuff to FIX on it. But it'd be nice if some other people even tried to USE it. > > Again, make no mistake. If you or anyone else wishes to develop > something of an experimental nature for FreeBSD then you should by all > means feel free to do so, but *in your own tree*. FreeBSD-current is > a good place to refine and test new mechanisms but not the place to > start placing the initial scaffolding in hopes that a few more > builders will show up and help you erect the supporting members of the > house. The time when that kind of approach was workable is well > behind us now and people simply need to adjust to that fact. On January 1 I will be checking in (with permission) a whole extra branch of the networking code. It will be (it is already) complete and working. it has been in SERIOUS production in 2.2 for most of a year. it requires no edits to external files other than /sys/conf/files yet it really makes most sense for this to go to 2.2.x first, and then migrate to 3.0, because it's been running in 2.2 for 9 months but has never been tested on 3.0. what's the consensus on this? > > Regards, > > Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346CDDE4.5656AEC7>