Date: Wed, 18 Jan 2012 12:13:19 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-hackers@freebsd.org, William Bentley <William@FutureCIS.com>, Robert Watson <rwatson@freebsd.org>, WBentley@FutureCIS.com Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <Pine.GSO.4.64.1201181147450.6287@sea.ntplx.net> In-Reply-To: <4F16A5B8.2080903@FreeBSD.org> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <alpine.BSF.2.00.1201181034580.51158@fledge.watson.org> <4F16A5B8.2080903@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1201181147450.6287>