Date: Mon, 17 Sep 2012 15:52:20 -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: <3649BB84-30A9-4765-8BB6-2484B4B88343@bsdimp.com> In-Reply-To: <50578D98.7080902@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> <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> <50578D98.7080902@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 17, 2012, at 2:52 PM, Doug Barton wrote: > On 09/16/2012 14:45, Warner Losh wrote: >>=20 >> On Sep 16, 2012, at 3:03 PM, Doug Barton wrote: >>=20 >>> 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!" >>=20 >> sysinstall replacement was a different discussion, with differing = technical criteria. >=20 > Right... in the sysinstall case we had a mainline system tool that was > actively being used, with no replacement in sight. It should not have > been removed until we had a viable replacement in the base. sysinstall's primary purpose was to install the system. It was also = useful for configuration, and that auxiliary part was missing. Given the = extreme barrier to entry for the replacement, it seemed wise at the time = to let bsdinstall in without the bsdconfig part. Given the bumps we've = had in bsdinstall, I think the push to get it in was premature from the = functionality it provided at the time. We've since mostly fixed it. > In the CVS case we have something that was _formerly_ in a similar > category, but is not any longer. cvs is still being used, but not in a primary role. I want to make sure = that the transition is fully documented with the new info before we cut = cvs loose. >> 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. >=20 > Careful! You're coming dangerously close to saying I was right about > something. :) You were right, but for the wrong reasons. :) Nah, I'll give you this = one. >>> Now that you are the one opposed to the change, we need to >>> keep HEAD "close to production ready." >>=20 >> Look at bz's push in this area.=20 >=20 > Yes, I think it's awesome that someone else has finally taken up the > "plz 2 stop brking teh head, kplztks" banner. Too bad it's still being > ignored. Lots of people say it, until they want something in the system that is = unstable... :) >> Also, I'm not opposed to this change, just opposed to this change = today, as explained elsewhere. >=20 > Doing it now has a lot of benefits, but ... >=20 >>> 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. >>=20 >> I believe that's already been done. >=20 > It isn't now, but it sounds to me like you're saying that you're not > opposed to doing so? MK_CVS moving to 'no' by default is something we can do right away, = since it is easy to figure out what went wrong for the people using cvs = and putting it back w/o needing to download anything new. Living behind = firewalls can make downloads a pita. I have had systems with very = specific holes that made it a PITA to download anything to them, and it = is a common occurrence. > Eitan, if you're listening, I'd strike while the iron is hot. :) Since I thought that had already been done, please do so. Please make = sure that ObsoleteFiles does the right thing too :) Oh, and make sure = UPDATING is updated. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3649BB84-30A9-4765-8BB6-2484B4B88343>