The MH-E repository

[Bill Wohler <wohler@newt.com>]

Back in 2001, I asked where the MH-E repository should go. Stefan
responded that using the Emacs repository would avoid the problems
incurred by the Gnus folks. But for one reason or another, the
repository ended up at SourceForge. Then in 2003, Richard suggested the
same thing to keep the Emacs version more fresh. While I keep the Emacs
version pretty fresh, and I've automated much of the importing and
exporting between the repositories, it's still work that could be
eliminated with a shared repository.

Now that there is a separate lisp/mh-e directory, and all of the MH-E
developers have signed papers and therefore should have write access or
be able to get write access to the Emacs repository, I'd like to ask
what folks think about moving the MH-E src module from SourceForge to
gnu.org.

I've listed some of the issues below and I invite comments from both the
Emacs maintainers and MH-E developers since these issues affect both
teams.

There may be some files mentioned below that the Emacs maintainers would
not want to see in the Emacs repository. Files will have to be organized
so that MH-E can be developed from within and outside of CVS Emacs, and
run as a released module from any supported version of Emacs.


Releases. Since MH-E has releases more frequently than Emacs, MH-E will
still need the ability to build its own releases.

Makefile and README. These files go in the MH-E release and are not
copied to lisp/mh-e in Emacs. The Makefile, which is used to build
mh-loaddefs.el and to build MH-E releases, could go in lisp/mh-e. The
file lisp/Makefile could be modified to run the mh-loaddefs.el target.
The import-emacs and import-emacs and install-emacs targets could be
eliminated ;-). I don't think it would hurt to add the README, which
contains instructions for building and installing MH-E, to lisp/mh-e
although it wouldn't need to appear in an Emacs release.

MH-E-NEWS. This file is copied from the MH-E src directory to the Emacs
etc directory. Since I'm the only one who edits this file and I already
have CVS Emacs checked out, I'm happy to edit this directly in etc.

Image files. The MH-E src directory contains images that are copied to
the Emacs lisp/toolbar and lisp/mail directories. Unless we did
something fancy, MH-E developers would have to check out the
lisp/toolbar and lisp/mail directories in addition to lisp/mh-e. We'd
have to figure out how to access the images from CVS Emacs, an installed
version of Emacs using both developmental MH-E and released MH-E.

mh-xemacs.el. This file in the MH-E src directory goes in the MH-E
release but not in GNU Emacs. Since it wouldn't hurt, it could go in
lisp/mh-e.

release-utils. This is a script that is used to perform various tasks
when making releases. It couldn't hurt to go in lisp/mh-e. It need not
appear in a release.

mh-unit.el. This file contains MH-E unit tests and runs checkdoc and
lm-verify before making releases. It couldn't hurt to go in lisp/mh-e.
It need not appear in a release.

contrib, debian, htdocs, xemacs modules. These would remain on
SourceForge.

Subversion. SourceForge has plans to offer Subversion this year. Are
there plans to move the Emacs repository to Subversion?


My two big questions are: 1) Is anyone against this, and why? 2) Would
the Emacs maintainers mind having the extra files mentioned previously
in the lisp/mh-e directory or would they prefer any files associated
with MH-E's life outside of Emacs to be kept outside of Emacs?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005