From owner-freebsd-stable Thu Jun 6 12:19:06 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27173 for stable-outgoing; Thu, 6 Jun 1996 12:19:06 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA27151; Thu, 6 Jun 1996 12:18:57 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA26483; Thu, 6 Jun 1996 13:18:40 -0600 Date: Thu, 6 Jun 1996 13:18:40 -0600 From: Nate Williams Message-Id: <199606061918.NAA26483@rocky.sri.MT.net> To: Terry Lee Cc: John Polstra , jkh@time.cdrom.com, nate@sri.MT.net, stable@freebsd.org, committers@freebsd.org, scanner@webspan.net Subject: Re: Status of -stable In-Reply-To: <31B72B95.1FD5@ienet.com> References: <199606061536.IAA00209@austin.polstra.com> <31B72B95.1FD5@ienet.com> Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FWIW, I think -stable is a wonderful thing. I even stated that to Jordan. *However*, I'm not the guy rolling the releases, and I have *NO* intention on doing it. I have enough fun trying to keep my little plate of projects working plus the occasional cleanups. That being said, I think we *could* stick with the -stable branch and just leave it as John suggested. If things actually go into -stable, it's because the developer does it, and *not* the release engineer. The person most qualified to do the merge, and given Jordan's hatred of CVS (some of it justified) we shouldn't expect him to do it. Now, on the flip-side, in order for -stable to continue working, a couple things *must* occur. First and foremost, developers must commit to bringing in changes to the -stable branch. If the developers aren't willing to bring in fixes to -stable (which gets more difficult over time as the environment diverge more and more, especially for the kernel.) I doubt you'll get any of the kernel developers to bring any significant changes over to -stable since with the VM and DEVFS changes, almost *everything* in the kernel is enough different where things aren't simple to bring over. Even the pccard and apm stuff are sometimes a pain to merge in -stable and -current and I've done almost *all* of the merging the last 5-6 months. Secondly, we *need* users to run -current, or else the whole point of -current becomes useless. FreeBSD is an experimental system to some degree, and unless the users test and help the developers debug the features of -current this project will get stale real fast. By making 'stable' continue on indefinitely, it encourages people to never try anything new and stick with 'tried and true'. Now, there's nothing wrong with that per-se, but if you want stability stick with a released version which for the most part is still more stable than running -stable. (Which the last couple weeks is a testament of. *grin*) Most of us do this because it's fun, and the fun stuff occurs in -current. The tradeoff is that sometimes in the midst of all this fun stuff you (or someone else) has way too much fun and introduces a bug in the system, which may/may not show up during testing. [ If you're having *lots* of fun you forget about testing and quickly commit your changes and then go watch the NBA finals or something like that, knowing that some geek w/out a life will immediately upgrade his sources and blow away his system testing out your code. *grin* ] > I'm not saying that you should do this or that, just expressing that the > -stable branch is very valuable in userland if only for a bug fixes and > new device drivers. Actually, the reason for the big 'merge' was that there are lots of userland fixes in -current that would be nice to have in -stable. However, bringing them in *after* the fact is a pain, and bringing them in at the original commit time is a mistake. Basically, if I bring in a fix to a user-land utility/library, it should go into -current to be beat on for 'a while to make sure the fix is valid unless it's really an obvious fix. Then, I should bring the fix into -stable once 'a while' has passed and the fix has been properly tested. The rub is that 'a while' is variable, and that once the fix is in the developer moves onto bigger/better things and forgets completely about the fix using the now-famous quote "It's been fixed in -current". Anyway, this is getting way too long and I *really* need to get back to fixing our iBCS2 emulation code for a project at work. I've found that 'gethostname' and 'uname' don't work right with regards to using FQDN. Nate