From owner-freebsd-hackers Sun Dec 17 03:39:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA22600 for hackers-outgoing; Sun, 17 Dec 1995 03:39:02 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA22594 Sun, 17 Dec 1995 03:38:57 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id MAA19398; Sun, 17 Dec 1995 12:30:10 +0100 (MET) Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id MAA00620; Sun, 17 Dec 1995 12:14:04 +0100 Date: Sun, 17 Dec 1995 12:14:04 +0100 (MET) From: Andreas Klemm To: "Jordan K. Hubbard" cc: current@FreeBSD.org, hackers@FreeBSD.org, cracauer@wavehh.hanse.de, jkh@FreeBSD.org Subject: Re: FreeBSD-current-stable ??? In-Reply-To: <7748.819191407@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 17 Dec 1995, Jordan K. Hubbard wrote: > > When speaking with people like Martin Cracauer, then I get > > the impression, that possibly more people would be interested > > to help in FreeBSD developement. Perhaps developing additional > > features, too. But they only have one machine, which shouldn't > > get into a very unstable state. > > > > So how could one attract more people, to work on the bleeding > > edge, without loosing stability too much ??!! > > I think the answer is pretty simple: > > People committing to -current need to get their acts together and stop > destabilising it so much. Yes, that's a somewhat sharply worded > statement, but I think that the split into 2.1 and 2.2 has been taken > by some to be implicit permission for a "free for all" in -current, > and that was NEVER the intention of that branch! Well, thanks Jordan for that statement. I don't think this isn't only a sharply worded statement, it was really needed. > If you've got something truly whacked-out experimental to bring in > then you're supposed to test it out on your own machine(s) to the > level where it, as an absolute minimum, does not make the system > unusable. If you can't reasonably guarantee this, then it should stay > in your local tree until you can. I'd love to see this to become true. > As Andreas notes here, having an unstable -current is very > counter-productive and only leads people away from wanting to run it > at all (I haven't updated my own -current system for a week or so, for > exactly this reason). So you should have raised your voice, too, Jordan, weeks and perhaps months ago ;-) Perhaps you remember the German phrase "Ist der Ruf erst ruiniert, dann lebt's sich voellig ungeniert" ;-) Concerning FreeBSD it means, that Unix engaged people like Martin, come to the clue, that -current developement isn't manageable, because you have an instable basis. What's even worse, Martin is one of our local Unix gurus in de.comp.os.unix. He is someone who "talks no shit". I think two months ago I got a report from him, that tries to compare the different PD Unixes .... I remember some statements, where he talks about the problem, that it's impossible to share the current developement, because it's done on an unstable system. And if you don't have two system, a production and a test (current) system, then you are stuck on release. I think other people may have been come to the same conclusion. You have the power to change this. I think it's really necessary. Little comparison with the dark side of Unix -> Linux :-> The have a as well a stable and a hackers branch, as we all know. When I was in the Linux camp several months (years?) ago, then I noticed, that the Linux hackers kernels are relatively stable, even the alpha stuff. Believe me or not. I think that having a well running -current branch would certainly bring - more 'happy home hackers' with - many new ideas - more feedback - a fresh drive (hehehe, join my excellent English here ;-) into the -current developement to the -current branch... I think it's a good possibility to find some new workhorses with many hp's ;-) > That somewhat defeats the purpose of -current, > which is to be a *final* testing ground for features. It's not a > dumping ground for half-baked and untested ideas that break existing > functionality. If you've got something truly left-field that you want > to bring in and it doesn't effect other parts of the system as a > whole, then the rules are perhaps somewhat more flexible, but this > definitely doesn't apply to changes to existing features. > > I think that the idea of further branching of FreeBSD into > -experimental and -current is not a good one, for various reasons: But it was perhaps a good idea, to describe the current scenario. Namely "That wishes arise because of the currnet bad situation". I already thought, that noone really wants a new branch, but people should start to think over their changes, if they are good or bad for those people, who are supping current. > 1. It would only encourage more mayhem in -experimental, quickly leading > to an unmanagable mess that nobody in their right minds would want to > run anyway (and if that's the case, then what's the point of committing > something to a central location? Just keep it in your own tree until > it's ready). > > 2. It would fragment work even more. People would be confused as to where > to commit, what with all these possible options. > > 3. Somebody would be stuck with merging changes between 3 branches instead of > two, and two is already becoming close to unmanagable (just ask David). Yeah, more work, less productivity. > Sorry to be so acidic, but I really do think that this needed to be > said, and messages like Andreas's here would only serve to indicate > that -current is way out of control. We need to regain some of the > credibility we've lost here, not make the problem even worse! So what could be done now ??? Reading Jordans comments we have to manage three things - keep the compiler happy code freeze and kick things out of current that are known to be so buggy, that the system panics or crashes or that badly influences other system services. Test them locally or in certain teams. make -current useable for a larger audience - keep the current-user happy keep in mind to add only tested things to -current which shouldn't be too difficult, since there aren't much people who are allowes to commit changes. - re-gain credibility, which means polish the somewhow damaged picture of -current Well after work is done, a big announcement in mailing lists and Newsgroups to motivate people for supping current. BTW: If you think there were too many changes made in current... So that one might come to the conclusion, that the next stable -current release will be FreeBSD-2.2-RELEASE ;-) What would you think about restarting over now. Get a fresh 2.1-stable source tree and make a project plan, what could go from old-unstable-current into the new current based on -stable without breaking it ?! If this would be done immediately, it would have the great advantage, that we all could immediately begin to sup current and to bring the new baby to work ! Then much more people could work on things like ext2fs, linux emulator and things like that. Like to hear your comments on that Good sunday you all Andreas /// -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de - \/ ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<<