Date: Sun, 16 Sep 2012 10:03:20 -0600 From: Warner Losh <imp@bsdimp.com> To: Eitan Adler <lists@eitanadler.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org Subject: Re: Fallout from the CVS discussion Message-ID: <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> In-Reply-To: <CAF6rxg=mm9OeVDX-dYC=FwnAZ-6pGjcRad=Gm9-mLx3QiPtqVQ@mail.gmail.com> References: <CAF6rxg=qVUHe7tc9_AXgRdUtkoHOrixwNw-GsN7C7_r0FR990A@mail.gmail.com> <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <CAF6rxg=mm9OeVDX-dYC=FwnAZ-6pGjcRad=Gm9-mLx3QiPtqVQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 16, 2012, at 6:34 AM, Eitan Adler wrote: > On 16 September 2012 01:35, Konstantin Belousov <kostikbel@gmail.com> = wrote: >> On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote: >>> However, -CURRENT is not meant to be a production system. >>=20 >> It is simply not true. >=20 > My statement was true, but does not disagree with the content below. > Production system !=3D Production Grade. One of the things we are trying to move towards is that current can be = cut into a release branch on short notice. We need to keep it as close = to production ready as possible. People do put -current systems into = production for testing purposes, or because they have made the = evaluation and know what they are doing. Discouraging production = systems from current, the present project policy, doesn't mean the = project doesn't appreciate the people that do put current systems into = production and the data that generates. Put another way: saying that current isn't meant for production systems = as a justification to slash things out before we are quite ready isn't = something people in general want to encourage, since it is close to = attitudes in the past that got us into a lot of trouble. Sure, in this = case the reaction is a bit of hyperbole, but there's long, historically = lingering wounds that put people on a hair trigger. >> CURRENT shall never be knowingly put into a state >> where it cannot be used for the 'production-grade' use, whatever it >> means. >=20 > Agreed. >=20 >> We do accept changes are so disruptive that some unknown fallout >> is expected, since otherwise developers cannot make any significant >> progress. >=20 > The point of my statement is that it perfectly acceptable to change > behavior in HEAD in a non-backwards compatible way. Some behaviors, yes. Most behaviors need to remain the same for a = variety of reasons. > In particular no > systems running -CURRENT are expected to be "critical functioning". Yes, they often are. > People that track -HEAD are expected to be able to deal with the sorts > of problems that occur from "drastic change." Generally yes. However, we do try to cushion the blows that are = delivered in -current. The reason we have the separation isn't so we = can do whatever we want in -current, it is so that when somebody messes = up, the damage is more limited. >> But introducing known breakage is simply not acceptable. Doing so = shrinks >> the already limited testing base we have for HEAD. >=20 > Agreed. Ditto. Sorry to be so pedantic on pushing the point in this meta-discussion, = but I don't want to see us slide back into the 'wild west' that current = was in the 5-current time frame. The CVS thing, by itself, wouldn't do = that, but we must have the proper attitudes for getting change done, and = when we pull the trigger on change. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51B48339-D1FA-49CD-B582-1C58855B024E>