From owner-freebsd-arch@FreeBSD.ORG Mon Sep 10 00:52:46 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82B5B1065670; Mon, 10 Sep 2012 00:52:46 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 288D58FC0C; Mon, 10 Sep 2012 00:52:46 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.5]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q8A0qgti025118; Sun, 9 Sep 2012 18:52:44 -0600 Date: Mon, 10 Sep 2012 07:52:41 +0700 From: Erich Dollansky To: Doug Barton Message-ID: <20120910075241.3994a95e@X220.ovitrap.com> In-Reply-To: <504D2DCD.8030508@FreeBSD.org> References: <20120908234659.GA10489@server.rulingia.com> <504BD9B5.20001@shatow.net> <504BE020.1070300@FreeBSD.org> <504BE12A.50907@shatow.net> <9A528A3C-40F1-4599-ACAB-EF306033A4F2@bsdimp.com> <86pq5vtj42.fsf@ds4.des.no> <20120910065532.3f029c4b@X220.ovitrap.com> <504D2DCD.8030508@FreeBSD.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , arch@FreeBSD.org Subject: Re: Removing CVS from HEAD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:52:46 -0000 Hi, On Sun, 09 Sep 2012 17:01:17 -0700 Doug Barton wrote: > On 9/9/2012 4:55 PM, Erich Dollansky wrote: > > I would suggest to keep it in the system and announce its end when > > older system like 8.x or 9.x are at the end of their life time. > > I think you misunderstand the proposal. No one is suggesting removing > CVS from FreeBSD 7, 8, or 9. It will _only_ be removed from what is > now HEAD, which will eventually be 10.0-RELEASE. > this is how I understand it. The problem I see is from the end-user perspective. They will upgrade to 10 and suddenly everything they developed stops working. I would suggest to start from the infrastructure side by getting more mirrors for the new system while phasing the mirrors for the old system out. Users are then not forced to make the sudden change. Please do not tell me that they should read UPDATING. They only will after they ran into trouble. Erich