Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Robert Watson <rwatson <at> FreeBSD.org>
Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Newsgroups: gmane.os.freebsd.devel.hackers
Date: Wednesday 18th January 2012 10:44:28 UTC (over 4 years ago)
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
 
CD: 3ms