From owner-freebsd-hackers Fri Apr 21 20:32:48 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA01402 for hackers-outgoing; Fri, 21 Apr 1995 20:32:48 -0700 Received: from psycfrnd.interaccess.com (psycfrnd.interaccess.com [198.80.0.26]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA01395 for ; Fri, 21 Apr 1995 20:32:46 -0700 Received: (joeg@localhost) by psycfrnd.interaccess.com (8.6.12/8.6.10) id WAA10435; Fri, 21 Apr 1995 22:30:13 -0500 From: Joe Grosch Message-Id: <199504220330.WAA10435@psycfrnd.interaccess.com> Subject: Re: Release stability (fwd) To: nate@trout.sri.MT.net (Nate Williams) Date: Fri, 21 Apr 1995 22:30:13 -0500 (CDT) Cc: hackers@FreeBSD.org Reply-To: joeg@truenorth.org In-Reply-To: <199504211928.NAA13261@trout.sri.MT.net> from "Nate Williams" at Apr 21, 95 01:28:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1927 Sender: hackers-owner@FreeBSD.org Precedence: bulk > >> > > In the old DEC world there was a three piece cycle that was followed >> > > many times. A feature release followed by a robustness release. There >> > > was also a performance release that followed the robustness release. > >> > Yes, I think that a new/stable/fast cycle of 3 has a lot to be said >> > for it. What would people say to us going to the following numbering >> > scheme in support of this? >> > >> > .<0,1,2[,3..]>[.] >> >> This is a very nice idea but it's going to take a lot of organisation on >> our part.... >> We don't currently have people interested in >> doing that sort of thing, everyone wants to play with the new toys. > >Actually, I'd be interested in doing such a thing except that I wouldn't >have the time to do it right. I think you could find some folks who'd >be willing to put the time in, but the problem is more of a technical >problem. > >The people who are qualified to accept/reject kernel patches don't have >the time to check the patches out. This was obvious in the 1.X -> 2.X >phase when folks posted patches. David didn't have the time to >back-port patches he had made to the new code which existed in the >previous code. > >I'm afraid this would be the same problem we're facing now. > I agree that the new/stable/fast method has a lot to offer. But there are a number of implicit assumptions in this method. a) that there are a good number of people working on this and b) that these people are divided up into groups, each working on a "phase". I don't think we have the man power to do this right particulary if we are doing each phase in less than 6 months. I suspect that the reason CSRG went with and stuck with the even/odd method is limited resources. My $0.02. Do with this as you wish. Josef -- Josef Grosch | joeg@truenorth.org | "Laugh while you can, monkey boy." finger for my | - Buckaroo Banzai - public PGP key |