emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Gnus Git synchronization with Emacs Bazaar (was: The Gnus repository is


From: Ted Zlatanov
Subject: Gnus Git synchronization with Emacs Bazaar (was: The Gnus repository is switching to Git as of 2010-04-19)
Date: Wed, 21 Apr 2010 06:03:56 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Tue, 20 Apr 2010 23:16:30 -0400 Stefan Monnier <address@hidden> wrote: 

>> Assuming this rename tracking works well, new files will be managed by
>> the Gnus synchronization maintainer.  The Emacs side should be
>> authoritative for new files, meaning that we (Gnus) will get lisp/new.el
>> and have to remove it, and that we will push our lisp/gnus-new.el to
>> your lisp/gnus/gnus-new.el.

SM> Hopefully Git can also figure out where to put new files.  But if not,
SM> I really can't imagine why you'd insist on doing it "all on the Git
SM> side".

To avoid working on the Bazaar side.

>> what other branches do we need immediately?

SM> We have the `emacs-23' branch which should sync with the "stable" branch
SM> of Gnus (not sure which one that is because I don't track Gnus
SM> development closely enough).

Reiner should decide this since he's been doing branches and tags in CVS
so far, but it probably makes sense to call our branch "emacs-23" as
well.  The branch name may be confusing because of the "emacs_23_1_RC"
branch we inherited from CVS, but with Emacs 24 and later the scheme
will work.

On Wed, 21 Apr 2010 12:31:03 +0900 "Stephen J. Turnbull" <address@hidden> 
wrote: 

SJT> *What I would do if I were you* is lobby for a new subtree, "packages",
SJT> of the Emacs tree, and just plop Gnus into that, with its Lisp and
SJT> support files all under packages/gnus.  Add a make rule which puts
SJT> appropriate Gnus autoloads into the loaddefs or whatever Emacs uses,
SJT> to find Gnus' Lisp and data in there.  (Directory symlinks would work,
SJT> as in XEmacs' "symlink farm installation" option, but aren't
SJT> acceptable as long as systems that can't symlink easily are
SJT> supported.)

I was planning to make Gnus one of the first package.el packages under
Emacs; we've discussed a separate "trusted FSF packages" repository
which will be better than the subtree you suggest.  Installing Gnus
through package.el will DTRT regardless.

But that doesn't eliminate the synchronization problem: we still want to
keep the current setup and let Emacs keep its own version of some Gnus
files like message.el.  Only lisp/gnus/*.el, some docs, and some images
will move to the Gnus package.

SJT> The way you're going, you're just making the same mistake XEmacs
SJT> made with its package system (having the installed tree look
SJT> different from the source tree), except that you're going to have
SJT> more pain than we do because of the possibility of shooting off
SJT> both your feet.

I think that Gnus is a special case and we shouldn't adapt Emacs'
packaging system to accomodate it.

Thanks
Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]