Date: Wed, 14 Mar 2001 21:59:36 -0500 From: "Patrick Bihan-Faou" <patrick@netzuno.com> To: <cvs-all@freebsd.org> Subject: Re: proposals for fixing the PROBLEM at hand Message-ID: <HJEEKLMFLKEOKHOKNPBMAEPICLAA.patrick@netzuno.com>
next in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?HJEEKLMFLKEOKHOKNPBMAEPICLAA.patrick>