Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Sep 2012 15:45:57 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Doug Barton <dougb@FreeBSD.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, Eitan Adler <lists@eitanadler.com>, arch@freebsd.org
Subject:   Re: Fallout from the CVS discussion
Message-ID:  <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com>
In-Reply-To: <50563EA6.1050908@FreeBSD.org>
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> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sep 16, 2012, at 3:03 PM, Doug Barton wrote:

> On 09/16/2012 09:03, Warner Losh wrote:
>> 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
>=20
> I find your response here interesting Warner, given that when I have
> opposed what I felt were too-drastic changes in HEAD (such as removing
> sysinstall before a post-install configuration solution was ready) =
your
> response has been, "It's HEAD, we can break things ... let's see what
> happens!"

sysinstall replacement was a different discussion, with differing =
technical criteria.

Also, using it against me now for consistency likely isn't so good.  I =
think we moved too quickly, in retrospect, on that.  That experience =
suggests we be more cautious in the future, including for things like =
this.

> Now that you are the one opposed to the change, we need to
> keep HEAD "close to production ready."

Look at bz's push in this area.  Also, I'm not opposed to this change, =
just opposed to this change today, as explained elsewhere.

> There is a compromise solution here that I have been hesitant to offer
> because I was really hoping that sanity would prevail. But why not
> switch the default MK_CVS knob over to "no" now? That will give us an
> opportunity to see if there really will be any fallout, and easily fix
> it if there is.

I believe that's already been done.

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99E30CDE-AC9D-4615-8830-5EC511EE1BBB>