From owner-cvs-all Wed Mar 14 18:58:24 2001 Delivered-To: cvs-all@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id D06DA37B718 for ; Wed, 14 Mar 2001 18:58:20 -0800 (PST) (envelope-from patrick@netzuno.com) Received: from jacuzzi ([24.200.106.26]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GA7XL802.0FQ for ; Wed, 14 Mar 2001 21:58:20 -0500 Received: from cognac (cognac.local.mindstep.com [192.168.10.4]) by jacuzzi (Postfix) with SMTP id 045A33DA5 for ; Wed, 14 Mar 2001 22:01:14 -0500 (EST) From: "Patrick Bihan-Faou" To: Subject: Re: proposals for fixing the PROBLEM at hand Date: Wed, 14 Mar 2001 21:59:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What about that bug that makes CAM work at 1/2 speed and the TCP stack at > > 1/4 the performance. Would you consider these bugs that should be > > committed to this branch? They certainly have no affect on the security > > of the released system. > > No, since CAM at 1/2 speed and TCP stack at 1/4 performance were part of > the feature set that existed when the production environment was > commissioned. If my production environment is working fine based on > those features then I'm not interested in any improvements since they > might destabilise my working environment. My applications might actually > rely on that poor performance, the last thing I'd want is for the > behaviour of the underlying OS that my application runs on to change. > > > > > > Perhaps what I consider to be a critical bug fix would always have > > > fallen into their definition of security anyway since I'm really only > > > talking about things that could cause data corruption or loss of > > > service > > > > Yes, you haven't spelled this out clearly before. > > To me "maintenance mode" has always meant critical bug fixes only, I > think that's a reasonably well understood definition in the industry. My > point has been all along that -stable is not in maintenance mode but is > being actively developed and we are therefore lacking a maintenance mode > option for production environment users. The -RELEASE branch sounds like > it will fill that gap but it's original remit of being security fixes > only isn't exactly the same as maintenance fixes only. I'd be happy with > the latter and would be willing to help support it. Humm... By reading this I have the very strong feeling that what you are advocating for is RELENG_3. As far as I know, since RELENG_4 is the official "STABLE" branch, RELENG_3 has gone in maintenance mode and apart for the few required security fixes has not changed much if at all in the last 6 months. I think that you are really asking for something that is not really practical: do you want to do this sort of maintenance on all the tagged release ? Right now that would mean 6 different flavors of RELENG_4 (4.0, 4.1, 4.1.1, 4.2, 4.3 and "stable" to maintain. This will quickly become a total nightmare. If your answer to this is we only "maintain" the last release, then I don't feel you provide any more benefits than the current situation, because with a release cycle of about 6 months, the so called "maintenance" version would still be a moving target with fairly significant feature/behavior changes every 6 months. I think that the overall philosophy is more or less: If I use "current", I expect to update my machine at least once a week. I definitely read the cvs-all and the current mailing lists. And file the occasional PR with the fixes I find necessary. If I use "stable", I update my machines every 1 - 1.5 months. This means that I have something that is evolving, but in quantifiable amounts at every update. And I actively read cvs-all to figure out when I want to do these upgrades. If I want a system that I can forget about (and I have a few of these), I install RELENG_3, and only when security related updates are announced do I upgrade them. The tradeoff that I am taking is exactly what you would find acceptable: the performance may not be the best (ATA, Softupdates, etc. not available), the features may be somewhat more limited (netgraph, nat, ipfw, etc.) but I know the quirks and I am only interested in security related fixes (named, ...). Also if I recall correctly there was a decision made after a fairly extensive thread on the "stable" mailing list that RELENG_3 would be maintained in exactly the manner you are asking for. As a side note, I would add that the RELENG_2_2 branch is also maintained for security patches only. So you really have 2 versions to choose from. I may have gotten your proposal completely wrong, so let me know if this is the case. Cheers, Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message