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 <address@hidden> writes:
> On Wed, 12 Aug 2009 06:50:36 -0700 Mike Kupfer <address@hidden> wrote: 
>
>>>>>>> "ST" == Stephen J Turnbull <address@hidden> 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