From: Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc: auctex-devel@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: CVS repository synchronization for RefTeX
Date: Mon, 1 Jan 2007 00:27:22 +0200 [thread overview]
Message-ID: <20061231222721.GA1424@kobe.laptop> (raw)
In-Reply-To: <87wt491b46.fsf@neutrino.caeruleus.net> <E1H0irq-0007S5-BO@fencepost.gnu.org> <uvejt1css.fsf@gnu.org> <85irftmi8p.fsf@lola.goethe.zz> <f89eae68edc85de02cd6c9d00661b11b@gmail.com>
Eli Zaretskii wrote:
But you might need to do that anyway, since some Emacs
features used by RefTeX will require a newer Emacs.
Besides, why not couple them? What's the problem?
Carsten Dominik <carsten.dominik@gmail.com> wrote:
RefTeX has always had a life outside the Emacs CVS repository,
to make it run with XEmacs and with non-CVS emacs. It is still
fully compatible with Emacs 21, and it caters for XEmacs as
well.
There are many people who use RefTeX but still use Emacs 21,
and even after the 22 release, this will be true for quite a
while.
This may require branching *inside* the Emacs CVS tree, i.e. to
create an `emacs-21' maintenance branch, but it's not something
unheard of. It's exactly the model used by FreeBSD, for example,
to maintain a separate "stable" branch along with the latest,
bleeding-edge HEAD of the CVS repository.
If the Emacs team agrees that such a maintenance Emacs 21.X
branch is ok to keep in the same CVS tree, you can use the
maintenance branch for bugfixes and/or features backported from
Emacs 22, as RefTeX or other Emacs 21 packages get updated.
David Kastrup <dak@gnu.org> wrote:
The people most likely to maintain it actively in future are
AUCTeX developers. Almost no maintenance has happened in the
Emacs repository up to now.
It's never too late, if it turns out that this can help the Emacs
and RefTeX teams work closely to integrate RefTeX into Emacs.
David Kastrup <dak@gnu.org> wrote:
RefTeX is released standalone (unsynchronized with Emacs
releases), and creating its tarballs and stuff requires
Makefiles and similar that are not present in the Emacs tree.
This is an artifact of the fact that RefTeX is maintained
separately from Emacs. It it was maintained as part of the same
integrated source tree, then RefTeX could use the Emacs build
process for these things, right?
David Kastrup <dak@gnu.org> wrote:
RefTeX also is maintained for XEmacs. What we have in Emacs is
just a fraction of the whole of RefTeX.
Do we have a fraction because the rest of RefTeX cannot be made
to work with GNU Emacs, or for some other reason? If this is
because of some other reason, what is this reason?
Eli Zaretskii <eliz@gnu.org> wrote:
Ralf said Emacs release cycle is too slow, but now you say that
there are many RefTeX users that still use Emacs 21. This
sounds like a contradiction to me.
Anyway, I just wanted to say that developing an Emacs package
outside Emacs bears additional burden. It is up to you to
decide whether that burden is justified.
Right. There are two different issues here, and I'm not sure if
they can both be solved in the `right' way:
* Maintaining RefTeX outside of Emacs means that there is going to
be integration effort every time a new `source-drop' of RefTeX has
to be merged into the Emacs source tree. We also lose any sort of
fine-grained file history we would have if the commits were done
directly in the CVS tree of Emacs.
* Maintaining RefTeX as part of the Emacs source tree reduces
integration effort, and lets us keep a better log of RefTeX
changes in the CVS tree of Emacs. It also means that RefTeX for
other Emacsen has to be maintained in *their* source tree though,
and risks a `fork' between the various RefTeX integration efforts
for all the different GNU Emacs versions and the other Emacsen.
I'm not sure if there is a good way to solve both problems.
Richard Stallman <rms@gnu.org> wrote:
Then there might be the problem that RefTeX is not in a releasable
state at the time an Emacs release is about to happen.
This is exactly why it is bad to maintain parts of Emacs in a separate
repository. Every such package causes difficulty for Emacs releases.
Exactly :)
Ralf Angeli <angeli@caeruleus.net> wrote:
If the part is maintained in a separate repository it is possible to
check code into Emacs' repository when it is in releasable state,
e.g. when a separate release of the part is being made. Then one can
go on developing in the separate repository without endangering Emacs'
state as a whole.
But this means that it is non-trivial to keep a history of the merges,
and resync the official source tree of GNU Emacs with the disconnected,
official tree of RefTeX.
The people who currently maintain cc-mode and Gnus may have useful
feedback, regarding the tools they use for the job. Do you think it's a
good idea to ask them and see what they have to say about the best way
to merge RefTeX source-drops with the CVS tree of Emacs and keep merging
updates, as they are committed to a separate RefTeX repository?
- Giorgos
next prev parent reply other threads:[~2006-12-31 22:27 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-28 22:53 CVS repository synchronization for RefTeX Ralf Angeli
2006-12-29 22:04 ` Stefan Monnier
2006-12-29 23:43 ` Ralf Angeli
2006-12-30 14:20 ` Eli Zaretskii
2006-12-30 15:08 ` Ralf Angeli
2006-12-30 15:20 ` Eli Zaretskii
2006-12-30 16:01 ` Ralf Angeli
2006-12-30 16:47 ` Carsten Dominik
2006-12-30 18:03 ` Eli Zaretskii
2006-12-30 18:50 ` Ralf Angeli
2006-12-30 19:03 ` Eli Zaretskii
2006-12-30 19:18 ` Ralf Angeli
2006-12-31 1:46 ` Richard Stallman
2006-12-30 21:28 ` Alan Shutko
2006-12-30 21:55 ` Reiner Steib
2006-12-31 22:27 ` Giorgos Keramidas [this message]
2006-12-31 23:57 ` Ralf Angeli
2007-01-01 7:09 ` Ways of keeping Emacs 22 and external projects in sync (was: CVS repository synchronization for RefTeX) Michael Olson
2007-01-01 15:21 ` Ways of keeping Emacs 22 and external projects in sync Ralf Angeli
2007-01-01 17:59 ` Reiner Steib
2007-01-01 18:36 ` Giorgos Keramidas
2007-01-03 10:43 ` Yavor Doganov
2007-01-03 18:32 ` Michael Olson
2007-01-03 18:29 ` Michael Olson
2007-01-03 19:53 ` Ralf Angeli
2007-01-03 22:37 ` Michael Olson
2007-01-01 18:20 ` Ways of keeping Emacs 22 and external projects in sync (was: CVS repository synchronization for RefTeX) Giorgos Keramidas
2007-01-01 21:56 ` CVS repository synchronization for RefTeX Richard Stallman
2006-12-30 18:23 ` Richard Stallman
2006-12-30 18:39 ` Ralf Angeli
2006-12-31 1:47 ` Richard Stallman
2007-01-01 16:01 ` David Kastrup
2007-01-02 3:09 ` Richard Stallman
2007-01-02 7:43 ` David Kastrup
2007-01-02 21:24 ` Richard Stallman
2007-01-03 8:48 ` David Kastrup
2007-01-04 2:31 ` Richard Stallman
2007-01-04 21:51 ` David Kastrup
2007-01-06 2:54 ` Richard Stallman
2007-01-06 9:14 ` David Kastrup
2006-12-30 21:54 ` Reiner Steib
2006-12-31 19:36 ` Ralf Angeli
2007-01-01 17:59 ` Reiner Steib
2007-01-01 19:12 ` Ralf Angeli
2006-12-30 22:07 ` Stefan Monnier
2006-12-29 22:59 ` Richard Stallman
2006-12-30 17:00 ` David Kastrup
2007-01-07 21:42 ` Bill Wohler
2007-01-08 19:25 ` [AUCTeX-devel] " Ralf Angeli
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=20061231222721.GA1424@kobe.laptop \
--to=keramida@ceid.upatras.gr \
--cc=auctex-devel@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.