From owner-freebsd-security Tue Oct 3 13:54:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 7FEB537B673; Tue, 3 Oct 2000 13:54:10 -0700 (PDT) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e93KrpX83062; Tue, 3 Oct 2000 13:53:52 -0700 (PDT) (envelope-from jkh@winston.osd.bsdi.com) To: Christopher Masto Cc: Warner Losh , Paul Richards , Kris Kennaway , Joseph Scott , Brian Somers , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: When to merge to stable [Re: cvs commit: src/usr.bin/finger finger.c] In-Reply-To: Message from Christopher Masto of "Tue, 03 Oct 2000 12:40:08 EDT." <20001003124008.A4892@netmonger.net> Date: Tue, 03 Oct 2000 13:53:51 -0700 Message-ID: <83058.970606431@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I think it's important to push _some_ features into stable. Having to > wait several years for the next major "point-oh" release of FreeBSD > (which comes with "point-oh fear" holding it back) is not the best > way to do things. IMO. There's a place between these two extremes > of paranoia and wild abandon, and I think that's where the MFCs should > take place. Which is essentially what the committer's guide tries to say. I have to agree with Christopher here - there's no hard-and-fast rule about merging which will result in 100% success at effectively balancing user-desired features with appropriate caution, except perhaps "BE CAREFUL!" We've made mistakes at both extremes of the spectrum in the past and, being frail humans, will probably make them in the future. If I had 3 wishes and could ask for anything I wanted, my first wish would be that were more "hands" involved with -stable and fewer public statements from various committers, as often seen in the past, disclaiming any interest in working with -stable or saying that it's too much trouble to keep up with anything but -current. That has a demoralizing effect on the people who DO value and work with -stable and sends the wrong message to our user base as well. We can't very well say that users should avoid -current out of one side of our mouthes and then say we don't do development in anything but -current out of the other side. We've also historically tried to be nice about this and not brow-beat our volunteer developers into having to go back and looking at "old code", leading to a situation where at least 95% of committers work in -current and some mysterious cadre of other folks handle the job of actually getting stuff back into -stable. I even often attempted to do that by myself until the diffs routinely got up into the 50MB range and I realized (and publically proclaimed) that that was way too much diffage to look at and the process was getting dangerously error prone as a result. People have since gotten a lot better about attending to -stable, don't think I haven't noticed that, but I think we still have a ways to go when it comes to the general committer perspective on it. Perhaps it's time to consider some changes to our policies on -stable? - Jordan P.S. No, I'm not going to tell you what my other two wishes would be. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message