From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Moving files from lisp/gnus/ to lisp/net/? Date: Mon, 25 Oct 2004 12:14:47 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <20041020105027.GA17283@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098699374 13296 80.91.229.6 (25 Oct 2004 10:16:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Oct 2004 10:16:14 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 25 12:16:06 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CM1tW-0006sk-00 for ; Mon, 25 Oct 2004 12:16:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CM219-0003ix-Rq for ged-emacs-devel@m.gmane.org; Mon, 25 Oct 2004 06:23:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CM20e-0003WI-BE for emacs-devel@gnu.org; Mon, 25 Oct 2004 06:23:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CM20d-0003VP-G3 for emacs-devel@gnu.org; Mon, 25 Oct 2004 06:23:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CM20d-0003Up-57 for emacs-devel@gnu.org; Mon, 25 Oct 2004 06:23:27 -0400 Original-Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CM1se-00088f-Fd for emacs-devel@gnu.org; Mon, 25 Oct 2004 06:15:12 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CM1sd-00084z-00 for ; Mon, 25 Oct 2004 12:15:11 +0200 Original-Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2004 12:15:11 +0200 Original-Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2004 12:15:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-To: emacs-devel@gnu.org Original-Lines: 38 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se Mail-Copies-To: nobody User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:fkrBUjGjH7QoyDvxXWtXZG8fIE4= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28893 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28893 Miles Bader writes: > Lars Magne Ingebrigtsen writes: >> Hm. That would work. But perhaps the best solution is to not move >> any files after all. :-) > > No, I think the files should be moved; the whole "but what about the > history?" issue is IMHO, vastly overrated -- it's a minor bump in the > road (if even that) that will make future operations smoother. > > Remember, the _info is still there_, just slightly more annoying to get > at. In my experience, looking at history is (1) not all that frequent > an event, and (2) almost always involves the last few file revisions; > point (2) is important because it means for commonly changed files, the > bump caused by file moving will cease to be an issue after a short while > (and for _un_-commonly changed files, well, they're not being changed > very often, so aren't something to worry about very much). > > Moving the files will simplify coordination with Emacs, and not just > with regard to the source-code "syncing" process: more importantly, it > will clearly communicate to Gnus developers the status of a file they're > working on, and make its relationship with Emacs obvious. > > Morever I think Gnus is large enough that some more directory structure > is a good thing even without Emacs coordination to worry about. One potential problem with a multi-directory structure is how to build Gnus. I'm not that familiar with the current code to build Gnus, but it is not as simple as 'emacs -f byte-compile-file foo.el' on each file. Someone will have to experiment with getting a multi-directory structure into a buildable state. There is also the problem if getting users to modify their load-path's to accommodate the new Gnus layout. I wouldn't mind if the files stay as they are in Gnus CVS. It seems the gains of a directory split are somewhat vague, and it isn't clear to me that a README.CVS wouldn't suffice.