From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 17:13:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361D4106564A for ; Wed, 18 Jan 2012 17:13:22 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id DDBE48FC2D for ; Wed, 18 Jan 2012 17:13:21 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id q0IHDJJT047791; Wed, 18 Jan 2012 12:13:19 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Wed, 18 Jan 2012 12:13:20 -0500 (EST) Date: Wed, 18 Jan 2012 12:13:19 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <4F16A5B8.2080903@FreeBSD.org> Message-ID: References: <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <4F16A5B8.2080903@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, William Bentley , Robert Watson , WBentley@FutureCIS.com Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 17:13:22 -0000 On Wed, 18 Jan 2012, Andriy Gapon wrote: > on 18/01/2012 12:44 Robert Watson said the following: >> My view is therefore that we have a "social" -- which is to say structural -- >> problem. Regardless of ".0" releases, we should be forcing out minor releases, >> which are morally similar to "service packs" in the vocabulary of other vendors: >> device driver improvements, new CPU support, steady of conservative feature >> development, etc, required to keep older major releases viable on contemporary >> hardware and with contemporary applications. One known problem is using a >> single "head" release engineer in steering all releases. I think this is a >> mistake, as it makes the whole project's release schedule subject to individual >> unavailability, burnout, etc, as well as increasing the risks associated with >> low bus factor. I'd like to see us move to a model where new release engineers >> are mentored in from the developer community for point releases, ensuring that >> we increase our expertise, share knowledge about release engineering in the >> broader community, and get new eyes on the process which can lead more readily >> to process improvements. The role of the "head" release engineer shouldn't be >> hands-on prodution of every release, but rather, steering of the overall team. >> >> I'd like to see this begin with 8.3, drawing a per-release lead from the >> developer community, and continue with a fixed schedule release of 8.4. Yes, >> more staffing is needed, but first, what is needed is an improvement in model. > > Robert, > > I think that in addition to what you suggest above it would also be useful to > have some sort of branch meisters. The current model when every developer > decides whether and when and where to do an MFC does not seem to be the proper > one. Developers often forget to do an MFC. Or decide against an MFC when there > is no reason to do so. Or sometimes do an MFC where the stable branch users > would rather prefer that it is not done. > There needs to be someone who "owns" a branch and who want to make it perfect. > Someone who could request an MFC (or even do it himself) and someone who could > reject an MFC. "someone who owns a branch..." - If you cut release N.0, do not move -current to N+1. Keep -current at N for a while, prohibiting ABI changes, and any other risky changes. If a developer wants to do possibly disruptive work, they can do it from their own repo. At this point, the branch meister(s) own the branch, and HEAD is only moved to N+1 when they decide that the branch is stable enough for production. Maybe then, N.1 (or N.2) is rolled out. I think most developers track HEAD because: you have to commit and test in HEAD before MFC'ing anyway; because of that, it easier to track and test one branch; and ports built for HEAD may not work on -stable. -- DE