From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 17:59:04 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28951065670 for ; Wed, 22 Dec 2010 17:59:04 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD728FC12 for ; Wed, 22 Dec 2010 17:59:04 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.3/8.13.6) with ESMTP id oBMHj7Wg039593 for ; Wed, 22 Dec 2010 11:45:07 -0600 (CST) (envelope-from mike@mail.karels.net) Message-Id: <201012221745.oBMHj7Wg039593@mail.karels.net> To: freebsd-arch@freebsd.org From: Mike Karels Date: Wed, 22 Dec 2010 11:45:07 -0600 Sender: mike@karels.net Subject: Re: Schedule for releases X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mike@karels.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:59:04 -0000 I'm replying to the thread as a whole rather than a specific message. I work for a security appliance vendor that may represent the worst case when it comes to supporting older FreeBSD releases. I spend a fair amount of time back-porting device drivers and other hardware support so we can run the older releases (back to 6.3) on new hardware. In fact, we haven't shipped a release based on 6.3 for two years, but we're still patching it to run on new hardware. Why so old, a FreeBSD developer asked recently? There are a number of factors, which are additive: - We have significant modifications to the system that have to be merged and retested in an OS upgrade. Of course, there is additional testing for an OS upgrade itself. - We try to do OS upgrades early in our release cycle, so our own software development will be done on the delivery platform. - We generally consider OS upgrades only for a major release of our own, usually a .0. These come less often than FreeBSD .0 releases. - We go through government certifications for some of our releases, but by no means all. These certifications take a long time. Many of our customers have to run the certified versions. We can sneak in new device drivers as a patch, but not an OS upgrade. - Security customers tend not to run our .0 releases, and often prefer not to upgrade to a major release for some time, e.g. a major network upgrade. For management and policy reasons, they want to keep their appliances at the same version, and upgrade to a major release is a lot of work. Even our internal customers aren't running a recent release. A few comments based on the above: - We realize that we're running an older release, and don't expect most of the improvements to be MFC'd. We know that we'll have to do some of the work to back-port drivers, etc, including testing. That said, it is helpful when the developers anticipate back-ports, e.g. leaving ifdefs in place for older versions of bus interface calls, vlan tags, etc. - We sometimes back-port other changes, such as TCP locking fixes that help performance. Considering some such things for MFC would be desirable. - Those of us doing backports could probably do a better job of sharing the results. On the other hand, I'm generally backporting to a specific release (currently 6.3 or 7.2) rather than -stable, and we're testing our software rather than FreeBSD. - Less frequent FreeBSD .0 releases would probabaly help us. - Changing the naming conventions might matter to some users, but wouldn't affect us much. I'm currently pushing for a 7.2 to 8.1 or 8.2 upgrade as part of a dot release, and the naming doesn't really matter to us. Mike