Date: Tue, 03 Oct 2000 18:32:28 +0100 From: Paul Richards <paul@originative.co.uk> To: Christopher Masto <chris@netmonger.net> Cc: Warner Losh <imp@village.org>, Kris Kennaway <kris@FreeBSD.ORG>, Joseph Scott <joseph.scott@owp.csus.edu>, Brian Somers <brian@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/finger finger.c Message-ID: <39DA182C.C70ED553@originative.co.uk> References: <39D98B55.126DAFC4@originative.co.uk> <200010022227.PAA62603@freefall.freebsd.org> <39D92E08.E00CF2E4@owp.csus.edu> <20001002180303.A40584@freefall.freebsd.org> <39D98B55.126DAFC4@originative.co.uk> <200010031530.JAA26493@harmony.village.org> <20001003124008.A4892@netmonger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Christopher Masto wrote: > > On Tue, Oct 03, 2000 at 09:30:13AM -0600, Warner Losh wrote: > > : I think we push too many enhancements from current to stable, when we > > : should really only push bug fixes onto the stable branch. The tendency > > : to add enhancements carries the risk of actually creating new bugs in > > : stable which is obviously not what we want to have happen. > > > > Exactly. We shouldn't be merging features at all, unless there's a > > compelling reason, the code has been reviewed by at least two people > > and it has had at least a month or two in current. If you can't find > > two people to review the code, then you can't merge it to stable due > > to lack of interest. > > The problem with being too cautious is that stable becomes unusable > and people who shouldn't be running current start moving to it because > stable doesn't support their new laptop. The people who are using FreeBSD in production environments need to have bug fixes made available for their stable version of the OS. If applying bug fixes de-stabilises their production environment then they're not very happy at all. I think the emphasis of the stable branch should be too support those production users. The users who are chasing features will always be pushing for a "stable current" and want the best of both worlds; new features *and* stability. Unfortunately that's an unachievable ideal and we shouldn't penalise those who really need the stability in trying to meet it. We're not applying sound software engineering practices anymore and that used to be what differentiated us from other projects. New code needs to be thoroughly tested before it's stamped as suitable for production use and I think the desire to make life easier, by merging things sooner rather than later when they might get forgotten about, is having a detrimental effect on the quality of stable. I think we should have a stable release team, that changes to the stable branch should be gated through to ensure they're thouroughly tested and that there's a need for them to be backported. I'd be happy to work with anyone else who wants to volunteer to do that since maintaining a stable version of the OS is a major issue for me with my new hat on. Paul Richards FreeBSD Services Ltd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39DA182C.C70ED553>