From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 10:58:06 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 332A41065689; Wed, 18 Jan 2012 10:58:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 140078FC08; Wed, 18 Jan 2012 10:58:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26277; Wed, 18 Jan 2012 12:58:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RnTDO-0008ar-5I; Wed, 18 Jan 2012 12:58:02 +0200 Message-ID: <4F16A5B8.2080903@FreeBSD.org> Date: Wed, 18 Jan 2012 12:58:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Robert Watson References: <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, WBentley@FutureCIS.com, Julian Elischer , William Bentley 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 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 10:58:06 -0000 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. Likely this could be the same person who then cuts a release from the branch. IMO. -- Andriy Gapon