Fallout from the CVS discussion

[Warner Losh]

On Sep 17, 2012, at 2:52 PM, Doug Barton wrote:

> On 09/16/2012 14:45, Warner Losh wrote:
>> 
>> 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
>>> 
>>> 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.
> 
> 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.
> 
> 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."
>> 
>> Look at bz's push in this area. 
> 
> 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.
> 
> Doing it now has a lot of benefits, but ...
> 
>>> 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.
> 
> 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