From owner-freebsd-hackers Sat Jul 22 17:11:14 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id RAA10656 for hackers-outgoing; Sat, 22 Jul 1995 17:11:14 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id RAA10650 for ; Sat, 22 Jul 1995 17:11:12 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Sat, 22 Jul 1995 19:11:07 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Jul 1995 19:11:09 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Support charges ( was Re: SUP target for -STABLE...) Cc: freebsd-hackers@freebsd.org Sender: hackers-owner@freebsd.org Precedence: bulk Jordan writes: >Well, I think it's less a matter of "INSIST" and more a matter of >"NEED". Once the organization is truly on the hook to provide a >product who's stability and reliability is a known quantity (inasmuch >as such can ever be known) then yes, it's going to have to have a lot >more control over what goes in and what doesn't. It simply won't be >able to exist otherwise since it couldn't deliver a guaranteed >response time with something that was constantly shifting under its >feet. I don't think that we disagree here. I simply used the word "insist" to point out that any reasonable programmer would require that this "need" be met. >However, as you suggest, I don't see this as much different than our >current STABLE branch scenario with all changes having to be approved >by one person (David) and a very tight degree of control being exerted >over it. Nobody has screamed about STABLE being unable to co-exist >with the current volunteer org and I'd say that it's more likely that >the volunteer org would be quite happy to have the rather constricting >and less-fun-and-more-business responsibility for STABLE go elsewhere. >The real joy has always been in hacking current where ideas and >general progress are less restricted. > >This doesn't mean that STABLE would be hidden from the world, and I'd >say that the snapshots and releases of it would still go out just as >regularly as they do now. I guess that what we really need to address is the "release" of a new system that would replace a supported "stable" version. That is the area where I see potential "turf" problems. If the support group does not have tight control on what goes in, they are burdened with the support headaches. If their selection is not sufficiently encompassing, they alienate the volunteers. IMHO, a fine line that will "make or break" the whole idea. > >This doesn't mean that STABLE would be hidden from the world, and I'd >say that the snapshots and releases of it would still go out just as >regularly as they do now. I would like to suggest that the -STABLE tree be distributed by CTM as well as other mechanisms. This mechanism is particularly appropriate when the changes are infrequent in nature. ---- Richard Wackerbarth rkw@dataplex.net