From owner-svn-src-all@FreeBSD.ORG Fri Dec 17 23:02:36 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E688E1065675; Fri, 17 Dec 2010 23:02:36 +0000 (UTC) Date: Fri, 17 Dec 2010 23:02:36 +0000 From: Alexander Best To: Alexander Leidinger Message-ID: <20101217230236.GA1151@freebsd.org> References: <201012161158.oBGBwoep051709@svn.freebsd.org> <20101216135547.B6126@maildrop.int.zabbadoz.net> <20101217171008.000010b5@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101217171008.000010b5@unknown> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Bjoern A. Zeeb" , src-committers@freebsd.org Subject: Re: svn commit: r216483 - head X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 23:02:37 -0000 On Fri Dec 17 10, Alexander Leidinger wrote: > On Thu, 16 Dec 2010 14:22:30 +0000 (UTC) "Bjoern A. Zeeb" > wrote: > > [descsription of the original ordering] > > I think grouping by date and then by file/lib/dir is actually better > > as it'll keep things logically together rather than possibly splitting > > it over 3 sections? > > As the person who did the initial ordering: whatever makes sense. Way > back when I did it, the original ordering made some things more easy. > Now that the lists grown very big, everyone is welcome to change it to > something which makes sense today. > > BTW: Should or should we not remove old entries which are way beyond > what we support, e.g. files from 2nd previous branches? The idea behind > is, that this prevents to have an abnormal big list of old stuff, and > that an update from e.g. 6 to 8 is not supported, so people need to go > from 6 to 7, can delete old stuff, update to 8 and delete again old > stuff. I am aware that people would have to rebuild all ports on 7 and > on 8 again, if they want to update libs. I am not sure if this matters. > If it matters, what about removing stuff which is from a 3rd previous > branch, e.g. if we delete on 8 it will remove outdated files from 7 and > 6, but not from 5? i've seen systems running 7 stable e.g. where sysadmins have never executed target delete-old and old files from the 2.x and 3.x days are still floating around. removing these ancient files from the delete-old target would mean that on such systems getting rid of such legacy files becomes close to impossible. personally i don't see a reason to get rid of those ancient entries. egrep -v '^#' ObsoleteFiles.inc|wc reports: 4972 5164 222607 which isn't really that much. just my 0.02$. cheers. alex ps: another possibility would be to have a target delete-old for old files from the last two releases and a new one called delete-ancient which will delete all the old stuff from way back. > > Bye, > Alexander. -- a13x