Gnus development mailing list
 help / color / mirror / Atom feed
From: Karl Fogel <kfogel@red-bean.com>
To: Ted Zlatanov <tzz@lifelogs.com>
Cc: ding@gnus.org, emacs-devel@gnu.org
Subject: Re: bzr for Gnus
Date: Tue, 08 Sep 2009 12:27:34 -0400	[thread overview]
Message-ID: <87ljkppfk9.fsf@red-bean.com> (raw)
In-Reply-To: <873a7xkr0k.fsf@lifelogs.com>

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




  reply	other threads:[~2009-09-08 16:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2009-09-09  3:11                 ` Stefan Monnier
2009-08-12  8:01         ` Miles Bader
2009-08-13 16:38           ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ljkppfk9.fsf@red-bean.com \
    --to=kfogel@red-bean.com \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=tzz@lifelogs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).