Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jan 2012 12:58:00 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org, WBentley@FutureCIS.com, Julian Elischer <julian@FreeBSD.org>, William Bentley <William@FutureCIS.com>
Subject:   Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Message-ID:  <4F16A5B8.2080903@FreeBSD.org>
In-Reply-To: <alpine.BSF.2.00.1201181034580.51158@fledge.watson.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F16A5B8.2080903>