Date: Tue, 03 Sep 1996 05:10:28 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: rkw@dataplex.net (Richard Wackerbarth) Cc: current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <9251.841752628@time.cdrom.com> In-Reply-To: Your message of "Tue, 03 Sep 1996 01:19:17 CDT." <v02140b02ae51760fc02b@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
> One advantage in going to this scheme is that you can eliminate the "sup" > as a separate product target. > > The "up-to-the-minute" folks should use CVSup. > > The next level, including the sup servers, can use the ctm delineated > "snapshots". The users can then either subscribe to ctm directly or sup the > equivalent product. > > The next level would be the "Jordan's snapshot" which you have given a bit > more testing than just "compiles". Precisely. > I guess I see that you and I have a different viewpoint of the "stability" > of things. No, not really. > In your model, "current" seems to be just some arbitrary collection of code. > whereas "stable" has been tested enough to make sure it compiles and runs. > You seem to leave out the "production" level which is supported. Nope, that's not my model at all. Please, do not confuse policy which arises from a reasonable apprehension of the trade-offs involved in relying on volunteer labor and lots of midnight coding (a frequent necessity for those with day jobs) with any personal ideal. In my ideal world, all changes would be tested all the time and the tree would never break. I'm sure it's an ideal all of core shares, for that matter, but it's only an ideal. Cold, hard reality dictates that if you want forward progress from a large volunteer army of people then you can't threaten to blow their heads off every time they make a mistake while taking their own initiative on something - you *need* them to be willing to take their own initiative if any real progress is to be made. There are lots of ways in which even the very best programmers in this project can (and do) make mistakes which break -current. Fixing a mistake may be simple, but it still requires a finite amount of time. The simple fact of the matter is that there is no fool-proof method for preventing programmer errors, and providing on-the-fly access to the development sources opens us far wider than *any* commercial UN*X vendor to having "customers" trip over problems when they occur. Hell, the concept of "production level" doesn't even make sense when discussing what's essentially a live snapshot of the engineering team's working sources and, if anything, the real problem here is that the WRONG PEOPLE are running -current! If you've achieved nothing else, you've definitely made the point to me that we've got a serious image problem with -current these days, namely that it's entirely *too* visible. -current was truly never intended to be something that the general user population ran freely and considered to be some sort of technology worth tracking on a day-to-day basis. -current was started simply as a developer-to-developer service with a very small group of people both reading and writing to it, very much as the engineering source tree would be maintained within a small company. Once in awhile we'd make a snapshot of it and those snapshots were all the public ever saw. There are some significant advantages to doing things in this way, actually, among which are the facts that: 1. You don't spend a lot of time writing emails in justification for your latest change to the entire world (and someone, somewhere will *always* disagree with you - it's a statistical law), you just duke it out in private with a small group of developers who also know their way around the system pretty well. Bang-for-byte ratio in email high, developer satisfaction high. 2. You don't have a large user base to support with the source syncronization tools, it's just you and 10-20 others at most. Support email comprises a significantly smaller percentage of your incoming load as a result. 3. You can attempt radical changes and experiments, if desired, without having to first obtain the concensus of a small army. Larger scale improvements are given much more room to happen. However, evolution took different paths with the various *BSD groups, and in the FreeBSD Project we decided fairly early on that, despite the many clear and obvious advantages to "keeping it in the family", as it were, we felt they came at too high a cost in denying access to those who might derive legitimate benefit from access to all the latest bits. So we threw the doors open on -current, shouting loudly "No guarantees! This is nothing more than a ``look over our shoulders'' from a software developer's perspective, folks! No warrantee given or implied! Extremely slippery when wet!" and we later followed this with general access to the CVS repository itself. Despite all of our disclaimers, however, we also seem to have taken on a whole host of miserable, nasty side-effects which inevitably come from making decisions like this. The hundreds of emails from people running -current, many of whom have no business doing so (and are strongly and openly dissuaded from so doing in the Handbook's section on -current). The frequent shouting from the peanut gallery (no, of course I don't mean *you*, dear reader :-). The people whining about how the engineering sources aren't "production quality" enough, balanced only occasionally in volume by the other folks complaining that FreeBSD's not innovating fast enough and is full of stale source code direly in need of updating. Sigh. No matter what trade-offs one takes, it seems, there's at least one immutable constant: "Ya just can't win!" :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9251.841752628>