FreeBSD has serious problems with focus, longevity, and lifecycle

[Robert Watson]

On Mon, 16 Jan 2012, Julian Elischer wrote:

> On 1/16/12 3:32 PM, William Bentley wrote:
>> I also echo John's sentiments here. Very excellent points made here. Thank 
>> you for voicing your opinion. I was beginning to think I was the only one 
>> who felt this way.
> [...]
>
>> We seem to have lost our way around the release of FreeBSD 7. I am all in 
>> favor of new features but not at the risk of stability and proper life 
>> cycle management.
>> 
>> Are me and John the only people that feel this way or are we among the 
>> minority?
>
> It pretty much boils down to one thing..  man power..

I disagree.  Resourcing is an issue, but it is not *the* issue.  The real 
issue here is a failure by the release engineering team (which includes me) to 
concurrently perform major and minor releases.  Given that minor releases run 
like clockwork in most cases, this is disappointing.  In the past, there have 
been a lot of good technical and structural obstacles to trying to do 
clockwork releases for both major and minor releases:

- Tight synchronisation of the ports and base release schedule means that the
   base release schedule limits ports productivity.

- Long freezes forced on us by poor revision control support for branching.

None of these really apply any longer -- and in as much as they do, they 
should be addressed.  In particular, I think there's a growing feeling that 
ports should be conducting its own releases out of lockstep with the base 
tree, producing package sets as a primary product at regular intervals 
regardless of the base release schedule.  Likewise, long freezes enforced by 
expensive branching operation in CVS no longer apply due to use of Subversion 
-- it's not perfect, but it's workable.

There's no way to satisfy everyone with any particular maintenance schedule 
and release cycle.  However, it seems clear that the current model with minor 
releases spaced at a year is satisfying no one.  It's easy to point at a 
developer<->user divide, but I think that misses the point: most developers 
are users.  A big gap between development branch and shipped features hurts 
the commercial users of FreeBSD that pay for so much of its development, since 
it forces them to support diverging local development and shipping products -- 
ISPs, etc.  There is no incentive for year-long gaps in minor releases.

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.

On a related note, the security team owns the "freebsd-update" mechanism, 
largely for historical reasons (Colin wrote it), but this is actually a bit 
backwards from how you would expect things to run, as we now use 
freebsd-update for upgrades, which are almost never engineered by the security 
team.  Not sure what the fix is there, but it seems related -- perhaps what is 
really called for is breaking out our .0 release engineering entirely from .x 
engineering, with freebsd-update being in the latter.

Robert