removing CVS in Handbook Updating and Upgrading chapter

[Isaac (.ike) Levy]

On Jan 26, 2013, at 9:26 PM, Eitan Adler wrote:
> On 26 January 2013 21:05, Warren Block <wblock at wonkity.com>
> 
>>> Not sure if I need to explain this, but:
>>> For a large number of system integrators, building userland/kernel from
>>> source is critical.
>>> Most of these builds happen before ports/pkg get installed, (if they even
>>> do).  The current state of SVN, binary packages, ports mechanism changes,
>>> and otherwise- all make for some nasty chicken/egg problems for many systems
>>> integrators.
> 
> We should certainly be striving to remove references to CVS from as
> many places as possible.  

That, I agree with, excepting fetching src/base for the buildworld;makeworld dance.

cvsup for base/src does not even have an end-of-life date yet, and the replacements are either:

- not clear
- not finished
- complex, confused, and difficult for systems integrators
  (people who buildworld/buildkernel as the stable base underneath everything)

> I have no objections to leaving one
> (obviously marked) chapter about the old way of doing things.

For developers, I can agree that cvsup is totally the wrong tool.
Yet, that information should maybe be in the developers handbook, perhaps in the "tools" section:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/tools.html

(If yall' think that's a good idea, I'll happily write up a page to start with)

>> This part of the Handbook refers to fetching source for -CURRENT or -STABLE.
>> We should not be suggesting CVS to new users who want to run development
>> versions of FreeBSD.  

Oh, I see your perspective, but FreeBSD systems administrators are well accustomed to running -CURRENT and -STABLE, along with -REL and -RELENG, in production.

Here's some circumstances admins may build STABLE:
- Prepping an environment for upcoming releases
- Providing QA/bugs back to FreeBSD *before* REL goes out the door
- STABLE may contain a necessary bugfix, security fix, or other necessary feature in a given environment

Here's some circumstances admins may build a given moment of CURRENT:
- All the same issues from STABLE could warrant some point of CURRENT
- some existing code may need to be manually backported quickly in an emergency
  (I've done my fair share of "grep hacking" to solve crisis situations as an SA)

I hope that's understood?

Best,
.ike