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

["Stephen J. Turnbull" <stephen@xemacs.org>]

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