Re: FreeBSD has serious problems with focus, longevity,

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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"