Re: GCC 3.1 Release

[Marc Espie <espie@quatramaran.ens.fr>]

In article <20020415171448.C1064@dragon.nuxi.com> you write:
>I strongly feel the GCC SC needs to take a stronger look at following the
>FreeBSD (and now OpenBSD) model of treating the release branch as not
>cast in stone.  A lot more things could be merged from 3.2 to 3.1 than I
>know will be.  It just takes creating the culture where committers are
>socially pressured to "merge from maintain" their changes where safe.
>IMHO too many changes are labeled "unsafe to merge" just so no one has to
>think about or deal with the merge.

Huh? What you describe is not OpenBSD's model at all.

We don't have branches. We have current, and every six months, we 
slow down, we stop development, we stabilize things, and we get out
a new release. In fact, it's probably 5 months devel/1 month bug-fix,
on average.

This works because of a few things:
- attention to detail,
- no excessive paperwork and rules (you had better not make a change
in an area that you don't own),
- a chief who can arbitrate conflicts,
- not too many bugs in the first place.

All these points are important. There is also a perceived quality
of the result that `tweaks' the development process: more time is
spent in fixing bugs if the release strays from our quality standards.

As far as the stable branch goes, we only commit very, very few
careful patches to it, and we NEVER add functionality to an old release.