Robert Watson wrote:
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.
It looks like Intel's development model. They have two teams. One works
on new
processor, while the second do upgrade of the previous one. On next turn the
last one start the new processor and the first one does.
I think it is great model.
[...]
_______________________________________________
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"
