* bzr for Gnus (was: Switching to bzr: what Emacs developers should know?) [not found] ` <87ab26aoix.fsf@canonical.com> @ 2009-08-11 18:56 ` Ted Zlatanov 2009-08-12 5:28 ` Stephen J. Turnbull 2009-08-12 8:01 ` Miles Bader 0 siblings, 2 replies; 8+ messages in thread From: Ted Zlatanov @ 2009-08-11 18:56 UTC (permalink / raw) To: emacs-devel; +Cc: ding On Tue, 11 Aug 2009 01:49:10 -0400 Karl Fogel <karl.fogel@canonical.com> wrote: KF> Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Actually, for Gnus it seems not particularly easy, because two-way >> merges like those Miles currently does don't seem to fit into the Bazaar >> model nicely at all and because merging two separate package histories >> into one seems to fit even worse. KF> Well, I should get a better understanding of how Gnus is developed, KF> before trying to write that section of the wiki. (Maybe my claim about KF> how it fits the Bzr model well is wrong...) KF> Is Gnus just in a separate CVS repository right now, and all the changes KF> get copied over in some primitive, history-destroying way when a new KF> Gnus is put into the Emacs distribution? If so, the Bright Shining KF> Future would be to simply version Gnus within the Emacs tree, and have KF> the Gnus developers maintain their own long-lived branches, just as with KF> anything else. They don't have to make changes outside the Gnus area KF> when they don't want to, after all. Miles does the synchronization, and it preserves history and changes from both sides well. FWIW, I'd be happy switching to bzr for Gnus work. I don't know how well that would work for the following common needs: - pull Gnus independently (for XEmacs users, including compatibility libraries) - pull Gnus by itself (no compatibility libraries, for Emacs users) - pull Gnus with Emacs (normal case) In addition, there's a difference between an independent Gnus repository synchronized with the Emacs repository and moving the entire Gnus repository inside Emacs. I don't know which one the Gnus developers would prefer, or even how such a move would be decided. My guess is that Lars Ingebrigtsen should at least be involved in the discussion in addition to the current Gnus contributors. KF> Unless Gnus devs do not want to switch to Bazaar? Can anyone here KF> answer, or should I be asking over in some Gnus forum? Gnus discussion is usually on the Ding list (ding@gnus.org) but most Gnus developers read emacs-devel as well. They may have missed your post, though, so I'm following up to it with a new subject and copying it to that list. Ted ^ permalink raw reply [flat|nested] 8+ messages in thread
* bzr for Gnus (was: Switching to bzr: what Emacs developers should know?) 2009-08-11 18:56 ` bzr for Gnus (was: Switching to bzr: what Emacs developers should know?) Ted Zlatanov @ 2009-08-12 5:28 ` Stephen J. Turnbull 2009-08-12 13:50 ` Mike Kupfer 2009-08-12 8:01 ` Miles Bader 1 sibling, 1 reply; 8+ messages in thread From: Stephen J. Turnbull @ 2009-08-12 5:28 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding, emacs-devel Bcc'ing some of the people mentioned below as "concerned with XEmacs packages" to ensure they see this post. Sorry for any dupes. Ted Zlatanov writes: > FWIW, I'd be happy switching to bzr for Gnus work. I don't know how > well that would work for the following common needs: > > - pull Gnus independently (for XEmacs users, including compatibility > libraries) > > - pull Gnus by itself (no compatibility libraries, for Emacs users) bzr doesn't support this out of the box, yet. Support for such "nested trees" is planned (greatly desired by many users) but implementation is not yet scheduled AIUI (there are some design details to work out). I don't speak for the bzr developers, but based on the history of features I've followed on the bazaar@canonical list I would be impressed if it stabilizes[1] in less than 6 months, and a little surprised if it takes more than 12 to implement and stabilize. bzr does support a "branch filtering" capability which could be used to emulate this. I'm not sure exactly how it works but it uses the fastimport feature, so it could be done on the Gnus side basically like maintaining a bidirectional mirror of a repo in a different VCS, except that all the difficulties related to "impedence mismatch" between VCSes would be avoided. A final option for nesting trees would be to use git or Mercurial to host the tricky parts; both have facilities (in git it's called "submodule") for handling the inclusion of Gnus in Emacs. git's is limited in the sense that nesting of submodules in submodules is not supported, but probably it would be be reasonably convenient to have a separate XEmacs branch which contains the XEmacs compatibility code. git would be my weapon of choice. An alternative to a kludgy nest of "xmas" in Gnus in Emacs would be to maintain the XEmacs compatibility code only in XEmacs package CVS, and not have it in Gnus "upstream" at all. Mike Kupfer has the authority to nominate committers for the Gnus package and normally access would be enabled within about 48 hours (an ssh key and user name are required so there's typically a bit of back and forth needed), and if he decides he likes the idea, that's good enough for us. (He'll probably consult with other directly interested parties such as Steve Youngs and Norbert Koch, of course, but the authority is his.) Of course that would involve some annoyance (eg, dealing with a separate checkout from our CVS as well as the mainline from Emacs's bzr) for anybody working on "xmas" code, but it's an option we can consider. Folks like Mike and Steve Youngs have done something similar to that for a long time, so they can give accurate advice on the amount of burden involved. Footnotes: [1] "Stabilize" in the sense of "at least as stable as a late prerelease of Emacs". ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr for Gnus (was: Switching to bzr: what Emacs developers should know?) 2009-08-12 5:28 ` Stephen J. Turnbull @ 2009-08-12 13:50 ` Mike Kupfer 2009-08-12 15:09 ` bzr for Gnus Ted Zlatanov 0 siblings, 1 reply; 8+ messages in thread From: Mike Kupfer @ 2009-08-12 13:50 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Ted Zlatanov, emacs-devel, ding >>>>> "ST" == Stephen J Turnbull <stephen@xemacs.org> 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. Hmm, I'll have to think about this. I'm reluctant to put the XEmacs-specific code off in a separate place. I suspect it would make it too easy for someone to change the common code and forget to make any corresponding changes in the XEmacs-specific code. Using nested repos might make that less of a concern, depending on the specifics of the tool and how the workflow is set up. mike ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr for Gnus 2009-08-12 13:50 ` Mike Kupfer @ 2009-08-12 15:09 ` Ted Zlatanov 2009-09-08 16:27 ` Karl Fogel 0 siblings, 1 reply; 8+ messages in thread From: Ted Zlatanov @ 2009-08-12 15:09 UTC (permalink / raw) To: ding; +Cc: emacs-devel On Wed, 12 Aug 2009 06:50:36 -0700 Mike Kupfer <mike.kupfer@xemacs.org> wrote: >>>>>> "ST" == Stephen J Turnbull <stephen@xemacs.org> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr for Gnus 2009-08-12 15:09 ` bzr for Gnus Ted Zlatanov @ 2009-09-08 16:27 ` Karl Fogel 2009-09-09 3:11 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Karl Fogel @ 2009-09-08 16:27 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding, emacs-devel 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 <tzz@lifelogs.com> writes: > On Wed, 12 Aug 2009 06:50:36 -0700 Mike Kupfer <mike.kupfer@xemacs.org> wrote: > >>>>>>> "ST" == Stephen J Turnbull <stephen@xemacs.org> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr for Gnus 2009-09-08 16:27 ` Karl Fogel @ 2009-09-09 3:11 ` Stefan Monnier 0 siblings, 0 replies; 8+ messages in thread From: Stefan Monnier @ 2009-09-09 3:11 UTC (permalink / raw) To: Karl Fogel; +Cc: Ted Zlatanov, ding, emacs-devel > Let's not make the Gnus merge recipe a prerequisite for switching. It's not. Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr for Gnus 2009-08-11 18:56 ` bzr for Gnus (was: Switching to bzr: what Emacs developers should know?) Ted Zlatanov 2009-08-12 5:28 ` Stephen J. Turnbull @ 2009-08-12 8:01 ` Miles Bader 2009-08-13 16:38 ` Stefan Monnier 1 sibling, 1 reply; 8+ messages in thread From: Miles Bader @ 2009-08-12 8:01 UTC (permalink / raw) To: emacs-devel; +Cc: ding Ted Zlatanov <tzz@lifelogs.com> writes: > Miles does the synchronization, and it preserves history and changes > from both sides well. BTW, I'll stop doing this when Emacs switches to bzr. -Miles -- Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr for Gnus 2009-08-12 8:01 ` Miles Bader @ 2009-08-13 16:38 ` Stefan Monnier 0 siblings, 0 replies; 8+ messages in thread From: Stefan Monnier @ 2009-08-13 16:38 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel, ding >> Miles does the synchronization, and it preserves history and changes >> from both sides well. > BTW, I'll stop doing this when Emacs switches to bzr. I assumed so much. Thank you again for the work you've done here, it has been most appreciated. Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-09-09 3:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <874osi6zpe.fsf@bzg.ath.cx> [not found] ` <28c656e20908081151h55a4b566v4cfc7c49c5ca2a37@mail.gmail.com> [not found] ` <jwvvdky6qia.fsf-monnier+emacs@gnu.org> [not found] ` <87ab26aoix.fsf@canonical.com> 2009-08-11 18:56 ` bzr for Gnus (was: Switching to bzr: what Emacs developers should know?) Ted Zlatanov 2009-08-12 5:28 ` Stephen J. Turnbull 2009-08-12 13:50 ` Mike Kupfer 2009-08-12 15:09 ` bzr for Gnus Ted Zlatanov 2009-09-08 16:27 ` Karl Fogel 2009-09-09 3:11 ` Stefan Monnier 2009-08-12 8:01 ` Miles Bader 2009-08-13 16:38 ` Stefan Monnier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).