From owner-freebsd-current@FreeBSD.ORG Fri Mar 5 09:41:41 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BBF61065676 for ; Fri, 5 Mar 2010 09:41:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7768A8FC16 for ; Fri, 5 Mar 2010 09:41:41 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B0AD746B38; Fri, 5 Mar 2010 04:41:40 -0500 (EST) Date: Fri, 5 Mar 2010 09:41:40 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <3620.1267780989@critter.freebsd.dk> Message-ID: References: <3620.1267780989@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, paradox Subject: Re: propose: all arch move into a separate dir X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 09:41:41 -0000 On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: > In message , Robert > Watso n writes: > >> Doing that kind of rearrangement [...] would be a nightmare for anyone with >> large [...] patches, so I'd say we could pretty much rule that out >> outright. > > I would say that we should do it occasionally, to encourage these FreeBSD > users to contribute as many of their local changes back to the project, as > possible :-) Absolutely -- and rearranging a tree is a good way to invalidate all those patches as well :-). It's a trade-off, obviously, but what it does mean is that we shouldn't rearrange the tree without thinking about both sides: it's not just the aesthetics of a particular layout over another, it's that changes in layout come with a less visible but much larger cost than "svn mv". Robert