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-unsubscr...@freebsd.org"
