Re: [PATCH] Abstract out a display-table-specific API (2)
Reiner Steib writes:
"Emacs Gnus" (= Gnus in the Emacs trunk) is the same as
"larsi Gnus"
(Gnus trunk from cvs.gnus.org), only some files (general purpose libs
not depending on Gnus) have been moved from emacs/lisp/gnus to other
places.
I seem to recall Richard suggesting moving some functions from one
file to another. Is my memory incorrect? Even if this time the
functions weren't moved, didn't he leave the possibility open for
future cases?
There are no plans to reflect that in Gnus CVS. (At least I
don't see
a strong benefit.)
OK. So we can assume that for the foreseeable future, Gnus
maintainers (upstream to some extent, but defintely downstream) are
going to have to be aware of several different organizations of the
code they maintain. This may have an impact on *our* decision to move
to a modern SCM for our packages.
Miles Bader maintains an arch repository of Gnus (and Emacs) which
he
also uses to sync Gnus branches, Gnus and Emacs and various Emacs
branches (see the "arch-tag" in every file).
I'm aware of that. However, as logical as the UI of Arch sounds when
Tom Lord explains it, it doesn't work out that way in practice. Since
Mike K already knows and likes Mercurial, that will work for us. I
don't really see a big advantage to moving to a Arch-to-Mercurial
workflow either.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta