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 <[EMAIL PROTECTED]> 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. _______________________________________________ Emacs-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-devel
