From owner-freebsd-current Tue Nov 14 09:40:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25702 for current-outgoing; Tue, 14 Nov 1995 09:40:01 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA25682 for ; Tue, 14 Nov 1995 09:39:47 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA28637; Tue, 14 Nov 1995 09:38:44 -0800 To: Terry Lambert cc: jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Tue, 14 Nov 1995 10:04:53 MST." <199511141704.KAA20129@phaeton.artisoft.com> Date: Tue, 14 Nov 1995 09:38:44 -0800 Message-ID: <28635.816370724@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > Uh, that would be the BSDI/CSRG relationship you are talking about, > right? 8-). No. I wasn't aware that BSDI ever actively supported CSRG - they merely profited most heavily from its dissolution. Perhaps you were merely being facetious, but that's not what I was talking about at all. > I think you have confused "commercial support" with "commercial Q/A and > support vis-a-vis specification compliance". No, I don't think so. > The concept of a commercial support organization does not necessitate > concommitant release engineering and product definition. You can fix > problems without setting policy or arbitrating product direction. I never said that it did. I simply said that having commercial responsibilities could and probably would necessitate a certain degree of autonomy. How great that autonomy would be is something that I doubt one could make hard and fast rules about, it would be something you'd have to set on a case by case basis and hence not something that endless discussion could "predetermine." I'm more than aware of the desirability of constructing general frameworks to work within, but there's also no substitute for a healthy dose of pragmatism in evolving such frameworks. > The easiest way would be to seperate the responsibility for -stable > and -current into two groups, and place the release engineering and > support services (which would take the form of control of the -stable > branch) into the support organizations hands. And keeping the -current > and other developement work seperate. That might be one way. I don't think there is only one, however. > polarized way. It's a setup for trouble. Linux avoids this because > Linus is the 400 pound gorilla: he is not overruled. It's a fine > line, though. No, Linus avoids the problem because Linus only concerns himself with a very small piece of the puzzle. He doesn't worry about user land and he doesn't concern himself with releases or support at all. With such a reduced mandate, the possibilies for conflict are significantly reduced. I think if he'd tried to take the whole piece for himself you'd have seen a general revolt long ago. > Will core allow an expedient soloution, or a conflicting soloution? Not > without some mechanism in place to force it on them, since they are > volunteers. You might as well attemptto force a merge of Net and Free; > you will have similar "success". I don't see it as necessary to force anything on anyone. The project *must* control its own code base just as the support organization controls its own. To insist on anything else would corrupt the mission of both organizations, and I don't see that as even remotely desirable. Naturally, this opens the door for divergence and all the other schizoid problems you pointed out, but that's just the breaks. How severe a problem it turns out to be is wholly determined by the reasonableness of the individuals involved, and if they can't be reasonable then we've got deeper problems that need to be addressed before even embarking on such a quest. > I think you are in a unique position to be able to do this, actually. > I'd caution against putting release engineering and support in the > same organization, however. It would, in my opinion, tip the scales > too far in the direction of expediency. Could be. Like I said, this would have to be a "we'll see" situation. You're also not adequately taking into account the fact that release engineering within the project is becoming an increasingly thankless job that has chewed through just about everyone available for the job. It may well reach a crisis point, in which case the arrival of a commercial org willing to take over the job in exchange for the cooperation of the developers ("we'll do the releases and ``donate'' them to the project for free in exchange for being able to turn around and sell those same releases with support") might well represent a heaven-sent salvation. We shall have to see! > I disagree. > > An organization can be no other than what it is. The design will dictate And I disagree in turn: "Stupid is as stupid does" :-) In an ideal world, design dictates events. In this one, design may dictate intention but actual events will follow much less deterministic lines. This isn't a situation where everyone will obediently troop to the little pidgeonholes you've created for them. > If you are going to tread this ground, tread carefully. Really? I would never have thought of that.. :-) Jordan