Fallout from the CVS discussion
Robert Watson
rwatson at FreeBSD.org
Mon Sep 17 09:47:19 UTC 2012
On Sun, 16 Sep 2012, Konstantin Belousov wrote:
> On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote:
>
> Removing the whole CVS discussion above, want to answer to seemingly
> unrelated note in your email, which I see as continuing very disturbing
> trend.
>
>> However, -CURRENT is not meant to be a production system.
>
> It is simply not true. CURRENT shall never be knowingly put into a state
> where it cannot be used for the 'production-grade' use, whatever it means.
> We do accept changes are so disruptive that some unknown fallout is
> expected, since otherwise developers cannot make any significant progress.
>
> But introducing known breakage is simply not acceptable. Doing so shrinks
> the already limited testing base we have for HEAD.
I'd argue that one of the greatest improvements in FreeBSD development in the
early 2000s was the shifting of high-risk work-in-progress development from
the CVS head to Perforce. This allowed the head to remain remarkably stable
during the multi-year SMPng, KSE, TrustedBSD, GEOM, etc, projects that would
otherwise have been remarkably disruptive. This trend has continued with
increased use of Subversion branches, Git/Mercurial repositories, etc.
Many companies develop their products alongside -CURRENT branches because they
need a long in-field product lifespan only accomplished by shipping based on
.0 or .1 releases, or because they are jointly developing a feature with other
members of the FreeBSD community. We definitely do not want to discourage
carefully reasoned use of -CURRENT in products, while recognising the risks
associated with an in-progress software revision. Certainly, we want to avoid
bumping developers off -CURRENT, and the goal should be to keep -CURRENT
maximially usable at all times -- in early FreeBSD development cycles, we saw
the severe problems associated with not doing so (e.g., 3.x-era VM work that
pushed many developers off -CURRENT for even personal work).
Robert
More information about the freebsd-arch
mailing list