From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: bzr for Gnus Date: Tue, 08 Sep 2009 12:27:34 -0400 Message-ID: <87ljkppfk9.fsf@red-bean.com> References: <87zla5ob1v.fsf@uwakimon.sk.tsukuba.ac.jp> <6283.1250085036@rawbw.com> <873a7xkr0k.fsf@lifelogs.com> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1252427331 18220 80.91.229.12 (8 Sep 2009 16:28:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2009 16:28:51 +0000 (UTC) Cc: ding@gnus.org, emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 08 18:28:44 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ml3Yf-0002Sx-KO for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2009 18:28:41 +0200 Original-Received: from localhost ([127.0.0.1]:55760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml3Ye-0000Ai-RC for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2009 12:28:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml3Xg-00089Y-KX for emacs-devel@gnu.org; Tue, 08 Sep 2009 12:27:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml3Xc-00085r-QU for emacs-devel@gnu.org; Tue, 08 Sep 2009 12:27:40 -0400 Original-Received: from [199.232.76.173] (port=36651 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml3Xc-00085h-KX for emacs-devel@gnu.org; Tue, 08 Sep 2009 12:27:36 -0400 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:47373) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml3Xc-0006jJ-7z for emacs-devel@gnu.org; Tue, 08 Sep 2009 12:27:36 -0400 Original-Received: from localhost ([127.0.0.1]:38214 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.69) (envelope-from ) id 1Ml3Xa-0005YQ-Qu; Tue, 08 Sep 2009 11:27:34 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115136 gmane.emacs.gnus.general:68974 Archived-At: A thought about the Bazaar switchover: Let's not make the Gnus merge recipe a prerequisite for switching. There are various ways to handle situations like Gnus's; I'm frankly not sure which is the best, and I think experimentation on the part of those closest to the code is going to be the only way to sort it out. But the way to make that experimentation happen is to make it a necessity. I don't mean that callously -- it's just the way things actually get done. That's how it went when Emacs used CVS too. That is, Emacs switched to CVS (easy enough, since it had been on RCS before that, IIRC), and externally versioned codebases that needed to integrate with that figured out how to do so on the fly as the need arose. That's what's going to happen here too. Does this sound sane? I'm just worried about creating needlessly huge blockers to the switchover. -Karl Ted Zlatanov writes: > On Wed, 12 Aug 2009 06:50:36 -0700 Mike Kupfer wrote: > >>>>>>> "ST" == Stephen J Turnbull writes: > ST> An alternative to a kludgy nest of "xmas" in Gnus in Emacs would be > ST> to maintain the XEmacs compatibility code only in XEmacs package > ST> CVS, and not have it in Gnus "upstream" at all. > > MK> Hmm, I'll have to think about this. I'm reluctant to put the > MK> XEmacs-specific code off in a separate place. I suspect it would make > MK> it too easy for someone to change the common code and forget to make any > MK> corresponding changes in the XEmacs-specific code. Using nested repos > MK> might make that less of a concern, depending on the specifics of the > MK> tool and how the workflow is set up. > > According to http://bazaar-vcs.org/BzrForeignBranches/Subversion > it may have to wait for the 'by-reference' work to be complete. > Meanwhile we can certainly set up something manual or automatic (a > MilesBot, if you will) to synchronize the Gnus CVS repo with the Emacs > bzr repo. As Stephen said, this may be months to 1+ years away. > > Ted