bzr for Gnus (was: Switching to bzr: what Emacs developers should know?)

bzr for Gnus (was: Switching to bzr: what Emacs developers should know?)

[Ted Zlatanov]

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

bzr for Gnus (was: Switching to bzr: what Emacs developers should know?)

[Stephen J. Turnbull]

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".

Re: bzr for Gnus

[Miles Bader]

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.

Re: bzr for Gnus (was: Switching to bzr: what Emacs developers should know?)

[Mike Kupfer]

>>>>> "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

Re: bzr for Gnus

[Ted Zlatanov]

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

Re: bzr for Gnus

[Stefan Monnier]

>> 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

Re: bzr for Gnus

[Karl Fogel]

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

Re: bzr for Gnus

[Stefan Monnier]

> Let's not make the Gnus merge recipe a prerequisite for switching.

It's not.


        Stefan