[Top][All Lists]

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

[AUCTeX-devel] Re: CVS repository synchronization for RefTeX

From: Giorgos Keramidas
Subject: [AUCTeX-devel] Re: CVS repository synchronization for RefTeX
Date: Mon, 1 Jan 2007 00:27:22 +0200

        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 <address@hidden> 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

    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

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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

reply via email to

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