From owner-freebsd-security Tue Oct 3 17:23: 7 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 2828137B502; Tue, 3 Oct 2000 17:22:55 -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 e940MeX84226; Tue, 3 Oct 2000 17:22:40 -0700 (PDT) (envelope-from jkh@winston.osd.bsdi.com) To: Paul Richards Cc: Christopher Masto , Warner Losh , Kris Kennaway , Joseph Scott , Brian Somers , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, freebsd-security@FreeBSD.org Subject: How long for -stable [ Re: cvs commit: src/usr.bin/finger finger.c ] In-Reply-To: Message from Paul Richards of "Wed, 04 Oct 2000 01:05:11 BST." <39DA7437.EAD39E03@originative.co.uk> Date: Tue, 03 Oct 2000 17:22:39 -0700 Message-ID: <84222.970618959@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > At the moment I can't see it working either since there's a strong > feeling from one side of the project that -stable should be closer to > the bleeding edge than the other side of the project would like and > until that is resolved any group of people trying to monitor what goes > into -stable is going to fall foul of one set of opinions or the other. Watching this discussion's highlights (lowlights? :) so far, I'd actually have to say that I'm tempted to go back and call for a revision of our existing policy which states that any -stable release more than 2 releases old is desupported. I was one of the authors of that policy and can only say that it seemed like a good idea at the time given the relatively small number of engineers we had and the frequent fights over unrealistic expectations that were occuring in the mailing lists. Nowadays we have a lot more engineers, however, and a lot more "customers" who are still running releases like 3.4 and would like *some* measure of support. I would therefore like to propose the following: We change the wording of our policy to state that upgrading to something within two releases of the "current -stable" product is the *recommended* action but that we will continue to provide, WHERE POSSIBLE, support for older branches of FreeBSD. We also stop telling people running 3.x (or whatever our "older -stable" might be at any given time) that they have to upgrade to receive any support at all and, instead, handle their queries on a case by case basis to see if it's possible for us to just whack whatever problem they might have over the head in the relevant branch and ask them to simply upgrade to the head of that branch. In cases where that's just not possible, we then ask them to jump up a branch. We could also look into providing an "update" command or something which would pull either sources or binaries over from a snapshot box and make the process of getting up to the branch-head a lot easier. It's long been on my wishlist and I'm at the point where I'd be willing to devote some BSDi resources to both writing the software and setting up a build box for creating the relevant binaries on an ongoing basis. This would seem to me to give us the best of all possible worlds. That portion of our customer base which wants a truly moribund -stable with just security enhancements and "by special request" fixes could have that by lagging back a branch. The other portion which wants a more active -stable could subscribe to the most current -stable. The final remaining portion which enjoys watching their blood come out in arterial spurts could subscribe to -current. :) What say? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message