Date: Mon, 17 Sep 2012 10:47:18 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Eitan Adler <lists@eitanadler.com>, arch@freebsd.org Subject: Re: Fallout from the CVS discussion Message-ID: <alpine.BSF.2.00.1209171044090.45319@fledge.watson.org> In-Reply-To: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> References: <CAF6rxg=qVUHe7tc9_AXgRdUtkoHOrixwNw-GsN7C7_r0FR990A@mail.gmail.com> <20120916053523.GJ37286@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1209171044090.45319>