CVS repository synchronization for RefTeX

CVS repository synchronization for RefTeX

[Ralf Angeli]

Hi,

maintenance of RefTeX will likely be continued by the AUCTeX project.
On the AUCTeX developers list it is currently being discussed how
maintenance of RefTeX will be done in its own CVS repository.
Something it hasn't had before.  Since RefTeX is also present in the
CVS repository of Emacs there might be the need to synchronize both
repositories to some extent.

What I am particularly concerned about is how maintainers of RefTeX
will be informed about changes made in Emacs' repository and how those
changes will get propagated back to RefTeX's repository.  AFAIK such
synchronization is handled automatically for Gnus by Miles.  Would it
be possible and sensible to provide something like this for RefTeX as
well?  How do other projects with repositories outside of Emacs, like
CC mode or MH-E, handle this?

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Stefan Monnier]

> maintenance of RefTeX will likely be continued by the AUCTeX project.
> On the AUCTeX developers list it is currently being discussed how
> maintenance of RefTeX will be done in its own CVS repository.
> Something it hasn't had before.  Since RefTeX is also present in the
> CVS repository of Emacs there might be the need to synchronize both
> repositories to some extent.

> What I am particularly concerned about is how maintainers of RefTeX
> will be informed about changes made in Emacs' repository and how those
> changes will get propagated back to RefTeX's repository.  AFAIK such
> synchronization is handled automatically for Gnus by Miles.  Would it
> be possible and sensible to provide something like this for RefTeX as
> well?  How do other projects with repositories outside of Emacs, like
> CC mode or MH-E, handle this?

How 'bout using the Emacs-CVS as *the* repository of RefTeX?


        Stefan

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Stefan Monnier (2006-12-29) writes:

>> maintenance of RefTeX will likely be continued by the AUCTeX project.
>> On the AUCTeX developers list it is currently being discussed how
>> maintenance of RefTeX will be done in its own CVS repository.
>
> How 'bout using the Emacs-CVS as *the* repository of RefTeX?

There will be standalone releases of RefTeX.  That means files for
building and installing RefTeX as well as files like README, INSTALL,
etc. would have to be added to Emacs' repository.  Those would mostly
be superfluous in an Emacs release and would have to be excluded from
pretest and release tarballs, unless they are considered only a minor
annoyance.

And we'll probably have to jump through some hoops for building
documentation and putting it into a RefTeX tarball as reftex.texi
currently is located in the man directory.

Then there might be the problem that RefTeX is not in a releasable
state at the time an Emacs release is about to happen.  Suppose I
would have had a major and risky change for RefTeX waiting to be
checked in about a year ago and held it back because Emacs is about to
be released.  I'd probably still not have it checked in.  Such a
situation nothing I'd be looking forward to.  Of course in an urgent
case one can back out such changes, but if you can avoid it ...

What about branching?  IIUC CVS branches can only be created for a
whole module.  Would it be okay to create a branch for all of Emacs if
one for RefTeX only were necessary?

Another issue might be that it will be harder for people to grab the
RefTeX sources from CVS if there is a fix they are interested in.  At
least with the current structure where the documentation is in a
different directory they'd have to check out the reftex directory (to
be created) and the documentation separately.

If RefTeX is to be maintained in Emacs' repository I'd actually like
to have all files (including documentation) in one dedicated
directory.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sat, 30 Dec 2006 00:43:04 +0100
> Cc: auctex-devel@gnu.org, emacs-devel@gnu.org,
> 	Carsten Dominik <carsten.dominik@gmail.com>
> >
> > How 'bout using the Emacs-CVS as *the* repository of RefTeX?
> 
> There will be standalone releases of RefTeX.

Why?  What problems is this going to solve that cannot be solved by
telling people to fetch files from the Emacs CVS?

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Eli Zaretskii (2006-12-30) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> 
>> There will be standalone releases of RefTeX.
>
> Why?

Because I don't want to couple the Emacs and RefTeX release cycles.

> What problems is this going to solve that cannot be solved by
> telling people to fetch files from the Emacs CVS?

I already answered part of that question in my last mail.  Apart from
that there are many users who are not really acquainted with CVS
(okay, there's the web interface) and with "installing" and
byte-compiling single files.  And if those users manage to do that
(probably by handholding them through the process) they'll get some
hodgepodge of files from releases and CVS.  And providing support for
such hodgepodge installations will be quite a nightmare.  I'd really,
_really_ like to avoid such a mess.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Cc: auctex-devel@gnu.org,  emacs-devel@gnu.org,  carsten.dominik@gmail.com
> Date: Sat, 30 Dec 2006 16:08:13 +0100
> 
> * Eli Zaretskii (2006-12-30) writes:
> 
> >> From: Ralf Angeli <angeli@caeruleus.net>
> >> 
> >> There will be standalone releases of RefTeX.
> >
> > Why?
> 
> Because I don't want to couple the Emacs and RefTeX release cycles.

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?

> > What problems is this going to solve that cannot be solved by
> > telling people to fetch files from the Emacs CVS?
> 
> I already answered part of that question in my last mail.

What, the need to get several files from different directories?
That's a non-issue, since a problem that urges a user to fetch a newer
file is normally solved in a single directory, if not a single file.
There's no need to fetch the docs if the problem is in Lisp.

> Apart from
> that there are many users who are not really acquainted with CVS
> (okay, there's the web interface) and with "installing" and
> byte-compiling single files.  And if those users manage to do that
> (probably by handholding them through the process) they'll get some
> hodgepodge of files from releases and CVS.  And providing support for
> such hodgepodge installations will be quite a nightmare.  I'd really,
> _really_ like to avoid such a mess.

This whole mess (and then some) will be completely avoided if you
decide to stick with Emacs releases.  If you don't, releasing interim
versions will get you at least some of the trouble, since users will
be installing those versions in several Emacs versions, and you will
have problem knowing which ones (as many people nowadays use the CVS
code).

I really, _really_ urge you to reconsider.

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Eli Zaretskii (2006-12-30) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> 
>> Because I don't want to couple the Emacs and RefTeX release cycles.
>
> But you might need to do that anyway, since some Emacs features used
> by RefTeX will require a newer Emacs.

RefTeX should be able to be used with both Emacs and XEmacs.
Therefore we'll need to cater for less capable Emacs releases anyway.

> Besides, why not couple them?  What's the problem?

The release cycle of Emacs is simply too long.

>> I already answered part of that question in my last mail.
>
> What, the need to get several files from different directories?
> That's a non-issue, since a problem that urges a user to fetch a newer
> file is normally solved in a single directory, if not a single file.
> There's no need to fetch the docs if the problem is in Lisp.

Which brings us back to the problem with a hodgepodge of files.  With
AUCTeX we are constantly having problems with people picking up
outdated documentation from the web instead of using the documents
accompanying each release, which are up-to-date and correctly reflect
the features and customization options.  Now you are suggesting to
introduce such incompatibilities with the integrated documentation as
well?  This is not good.

>> Apart from
>> that there are many users who are not really acquainted with CVS
>> (okay, there's the web interface) and with "installing" and
>> byte-compiling single files.  And if those users manage to do that
>> (probably by handholding them through the process) they'll get some
>> hodgepodge of files from releases and CVS.  And providing support for
>> such hodgepodge installations will be quite a nightmare.  I'd really,
>> _really_ like to avoid such a mess.
>
> This whole mess (and then some) will be completely avoided if you
> decide to stick with Emacs releases.  If you don't, releasing interim
> versions will get you at least some of the trouble, since users will
> be installing those versions in several Emacs versions, and you will
> have problem knowing which ones (as many people nowadays use the CVS
> code).

We'll be defining which versions of Emacs and XEmacs RefTeX will be
compatible with, just like we are doing it now with AUCTeX.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Carsten Dominik]

On Dec 30, 2006, at 16:20, 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?

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.  I wanted to get bug fixes and new features to these users.
Since Emacs does not have a packaging system that allows the user
to easily update a package, and since the release cycle is
(at least currently) extremely long, distributions outside
of Emacs have always been necessary.

So even up to now, RefTeX has had its own CVS, into which I
have merged any changes done on the Emacs side.  So nothing
fundamental will change once the AUCTeX project takes over
maintenance and distribution.

- Carsten

Re: CVS repository synchronization for RefTeX

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org,
>  Ralf Angeli <angeli@caeruleus.net>,
>  auctex-devel@gnu.org
> From: Carsten Dominik <carsten.dominik@gmail.com>
> Date: Sat, 30 Dec 2006 17:47:55 +0100
> 
> On Dec 30, 2006, at 16:20, 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?
> 
> 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.

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.

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Eli Zaretskii (2006-12-30) writes:

> 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.

As Carsten wrote, RefTeX has been mainained outside of Emacs and seen
releases independent of Emacs ever since.  So there currently is no
problem with the length of Emacs' release cycle.  There would be a
problem, however, if one followed your suggestion not ot release
RefTeX independently of Emacs anymore.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sat, 30 Dec 2006 19:50:58 +0100
> Cc: auctex-devel@gnu.org, emacs-devel@gnu.org,
> 	Carsten Dominik <carsten.dominik@gmail.com>
> 
> * Eli Zaretskii (2006-12-30) writes:
> 
> > 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.
> 
> As Carsten wrote, RefTeX has been mainained outside of Emacs and seen
> releases independent of Emacs ever since.  So there currently is no
> problem with the length of Emacs' release cycle.  There would be a
> problem, however, if one followed your suggestion not ot release
> RefTeX independently of Emacs anymore.

Sorry, but you are just reiterating the contradictory statement
without explaining it.

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Eli Zaretskii (2006-12-30) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> 
>> As Carsten wrote, RefTeX has been mainained outside of Emacs and seen
>> releases independent of Emacs ever since.  So there currently is no
>> problem with the length of Emacs' release cycle.  There would be a
>> problem, however, if one followed your suggestion not ot release
>> RefTeX independently of Emacs anymore.
>
> Sorry, but you are just reiterating the contradictory statement
> without explaining it.

Hm, then I probably fail to see the contradiction.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

If RefTex already has its own separate repository, moving that into
AucTeX shouldn't cause any added problem.

Re: CVS repository synchronization for RefTeX

[Alan Shutko]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

Having RefTeX on a separate release cycle than Emacs allows people to
keep a stable Emacs base system, but pick up RefTeX improvements
without needing to upgrade everything else that comes with Emacs at
the same time.  It also allows people to get RefTeX updates without
waiting years for an Emacs release.  Many people don't want to track
Emacs CVS, but would be willing to track released updates of a
specific component.

Carsten once made some changes to improve indexing a specific case for
me, and it was very nice that I could get them without going into CVS
or waiting for an Emacs release.

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
Don't you just hate it when they verbify nouns?

Re: CVS repository synchronization for RefTeX

[Reiner Steib]

On Sat, Dec 30 2006, Eli Zaretskii wrote:

> Carsten Dominik 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.
>
> 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.

People who don't want to (or can't [1]) upgrade to Emacs 22 are not
necessarily the same people as the ones who want a never version of
$package.

Some other example: Emacs 21 comes with Gnus 5.9 which was released in
1999 [2].  In case of [1], (s)he can still install a much more recent
stable Gnus (5.10.8, released 2006; only bug fixes to 5.10.1, release
2003).

> Anyway, I just wanted to say that developing an Emacs package outside
> Emacs bears additional burden.

ACK.  If Miles wouldn't do the work of syncing Gnus and Emacs
repositories, it would again imply much work for the next but one
Emacs release.

Bye, Reiner.

[1] E.g. if the sysadmin doesn't wan to install non-release software.

[2] Not only the long release cycle of Emacs, but also the long
    release cycle of Gnus is responsible for this.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: CVS repository synchronization for RefTeX

[Giorgos Keramidas]

        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

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Giorgos Keramidas (2006-12-31) writes:

>     Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>     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,

We are not talking about maintenance, but about regular development
which involves new features.  RefTeX is supposed to progress and stay
compatible with Emacs 21 and XEmacs at the same time.

>     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?

No, because it would not be possible to install a new standalone
version of RefTeX.

> 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.

I don't see a big benefit in having the history directly in Emacs.  If
you are interested in it, you can get it from the separate repository.

>     * 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,

Again, there is one RefTeX and that is supposed to work with different
Emacs and XEmacs versions.

>       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.
>
>     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,

You'll have the history in Emacs' CVS repository.  With an entry every
time a release of RefTeX is checked into the Emacs repository.

> and resync the official source tree of GNU Emacs with the disconnected,
> official tree of RefTeX.

That depends if changes to RefTeX files in the Emacs repository are
allowed, which I would be in favor of.  In that case we'd need some
way of transferring changes made in the Emacs repository into the
RefTeX repository; preferrably automatically.  That's what the subject
of this message refers to.

> 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?

Well, I was hoping for some of them to chip into this thread.

-- 
Ralf

Ways of keeping Emacs 22 and external projects in sync (was: CVS repository synchronization for RefTeX)

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 5018 bytes --]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Giorgos Keramidas (2006-12-31) writes:
>
>> 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?
>
> Well, I was hoping for some of them to chip into this thread.

I guess I'll chip in with how I manage to keep the development version
of ERC synced with that included with Emacs 22.  Gnus does it slightly
different than I do, because they merge directly to Emacs 22, rather
than using an intermediary branch like I do.

I use GNU Arch to maintain ERC.  Among the various branches are these:

erc--main--0 :: Where development happens

erc--rel--5.1 :: Where the currently previous major release (5.1) gets
  updated when it is time to prepare a minor release.

erc--emacs--22 :: The branch which is used to sync to and from the
  version in Emacs 22.

emacs--devo--0 :: The equivalent of CVS HEAD for Emacs in Arch, kept
  in sync by Miles Bader.

* Preparation

When preparing the Emacs 22 version of ERC for the first time, I added
explicit Arch tags to all of the files which would be included with
Emacs 22.  Namely: all .el files that don't depend on anything outside
of the Emacs source tree, NEWS (renamed etc/ERC-NEWS in Emacs 22),
ChangeLog, and the manual.  This way, even if the files are in
different directories, Arch can sort them out.

I then set up a couple of scripts (in a scripts/ directory that only
exists in the erc--emacs--22 branch) that help me sync to and from the
Emacs 22 source tree.

common.defs:
===
# Common definitions for syncing ERC             -*- Shell-script -*-

EMACS=~/proj/emacs/emacs
ETC=$EMACS/etc
LISP=$EMACS/lisp
MAN=$EMACS/man
===

sync-from-emacs:
===
#!/bin/bash

# Load common definitions
. scripts/common.defs

(cd $LISP/erc && find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $OLDPWD \;)
cp $ETC/ERC-NEWS etc/
cp $MAN/erc.texi man/
rm -f *.elc
===

sync-to-emacs:
===
#!/bin/bash

# Load common definitions
. scripts/common.defs

(cd $LISP/erc && find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $OLDPWD \;)
cp $ETC/ERC-NEWS etc/
cp $MAN/erc.texi man/
rm -f *.elc
===

* Syncing changes

When there are some changes that need to be propagated to Emacs 22, I
first check emacs--devo--0 to see if someone changed things on the
Emacs side, by running ./scripts/sync-from-emacs.  If anything is
different than the current contents of erc--emacs--22, I immediately
check them in (to erc--emacs--22).

Then, I apply the necessary changes from erc--main--0.  Once all of
the conflicts have been resolved, I check in the code and run
./scripts/sync-to-emacs.  I then check to see whether Emacs still
compiles.  Depending on how large the changes are, I may test them.
Then, if changes were made to files outside of lisp/erc in the Emacs
tree, I add log entries for them in their respective directories.
That done, I check the changes in to emacs--devo--0 with a brief log
entry.

* Closing thoughts on related subjects

I think it is unrealistic to expect that large, active projects which
are included with Emacs 22 use the Emacs source tree for their main
development area.  It makes much more sense for such projects to just
merge in critical updates and new releases.  It also makes rapid
development easier, because operations on the revision control system
of choice take significantly more time on the entire Emacs tree as
compared to just the files of the individual project.

I also think it is a very bad idea for Emacs developers to mandate
checking in files individually.  It might make sense for work on the
core files in lisp/emacs-lisp/ or the top-level of lisp/, but a
significant percentage of changes made to the other lisp files involve
changing several files at once.  Separating log entries for commit
messages begins to become a burden.  For operations such as updating
an entire project, this would become very tedious (not to mention
unnecessary, because ChangeLog contains all the information that is
really needed).

With Arch, such changes are treated as a single change to the entire
project, rather than multiple separate changes to single files.  There
is no possibility (however remote) of changes to several files being
only partially applied, as long as Arch is the only version control
system involved.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Ways of keeping Emacs 22 and external projects in sync

[Ralf Angeli]

* Michael Olson (2007-01-01) writes:

> I guess I'll chip in with how I manage to keep the development version
> of ERC synced with that included with Emacs 22.  Gnus does it slightly
> different than I do, because they merge directly to Emacs 22, rather
> than using an intermediary branch like I do.

AFAIK changes to Gnus files in Emacs' repository will be transferred
automatically via Miles' Arch repositories to Gnus' stable branch.
I'm not sure how changes relevant to the trunk are moved there.

> I use GNU Arch to maintain ERC.  Among the various branches are these:
>
> erc--main--0 :: Where development happens
>
> erc--rel--5.1 :: Where the currently previous major release (5.1) gets
>   updated when it is time to prepare a minor release.
>
> erc--emacs--22 :: The branch which is used to sync to and from the
>   version in Emacs 22.
>
> emacs--devo--0 :: The equivalent of CVS HEAD for Emacs in Arch, kept
>   in sync by Miles Bader.
[...]
> I then set up a couple of scripts (in a scripts/ directory that only
> exists in the erc--emacs--22 branch) that help me sync to and from the
> Emacs 22 source tree.
[...]
> sync-from-emacs:
> ===
> #!/bin/bash
>
> # Load common definitions
> . scripts/common.defs
>
> (cd $LISP/erc && find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $OLDPWD \;)
> cp $ETC/ERC-NEWS etc/
> cp $MAN/erc.texi man/
> rm -f *.elc
> ===
>
> sync-to-emacs:
> ===
> #!/bin/bash
>
> # Load common definitions
> . scripts/common.defs
>
> (cd $LISP/erc && find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $OLDPWD \;)
> cp $ETC/ERC-NEWS etc/
> cp $MAN/erc.texi man/
> rm -f *.elc
> ===

The scripts look identical.  Is that correct?

> * Syncing changes
>
> When there are some changes that need to be propagated to Emacs 22, I

So you are updating ERC in Emacs not on a release-by-release basis,
but rather when some important changes need to be propagated?  Do you
apply a tag in that case in order to identify the file revisions if
somebody has a bug report or support request referring to the ERC
version in Emacs or do you just use the files in Emacs directly for
testing and debugging?

> first check emacs--devo--0 to see if someone changed things on the
> Emacs side, by running ./scripts/sync-from-emacs.  If anything is
> different than the current contents of erc--emacs--22, I immediately
> check them in (to erc--emacs--22).

Do you regularly synch from Emacs or just when you are about to synch
to Emacs?

My idea for RefTeX would have been that a synch from Emacs to RefTeX
is done regulary, but directly instead of using an intermediate
repository.

> I also think it is a very bad idea for Emacs developers to mandate
> checking in files individually.  It might make sense for work on the
> core files in lisp/emacs-lisp/ or the top-level of lisp/, but a
> significant percentage of changes made to the other lisp files involve
> changing several files at once.  Separating log entries for commit
> messages begins to become a burden.  For operations such as updating
> an entire project, this would become very tedious (not to mention
> unnecessary, because ChangeLog contains all the information that is
> really needed).

That reminds me: When you are synching from Emacs to ERC (and vice
versa) the ChangeLog file is probably handled the same way Lisp files
are.  Because log entries of changes to RefTeX in Emacs currently end
up in lisp/ChangeLog we'd need a separate ChangeLog file for RefTeX
for this to work.

> With Arch, such changes are treated as a single change to the entire
> project, rather than multiple separate changes to single files.  There
> is no possibility (however remote) of changes to several files being
> only partially applied, as long as Arch is the only version control
> system involved.

As Savannah supports Arch repositories now it should be no problem to
maintain RefTeX in such a repository.  What I would be missing with
Arch would be something like PCL-CVS and the web interface like
Savannah provides it for CVS repositories.

-- 
Ralf

Re: Ways of keeping Emacs 22 and external projects in sync

[Reiner Steib]

On Mon, Jan 01 2007, Ralf Angeli wrote:

> AFAIK changes to Gnus files in Emacs' repository will be transferred
> automatically via Miles' Arch repositories to Gnus' stable branch.
> I'm not sure how changes relevant to the trunk are moved there.

I'm not sure which changes (to which trunk?) you have in mind here.

The section "Syncing" in texi/gnus-coding.texi [1] in the Gnus trunk
(maybe it would be useful to add this file to Emacs CVS in
emacs/admin/?) describes the process.  Feel free to ask if something
is missing or unclear there.

Bye, Reiner.

[1]
http://quimby.gnus.org/cgi-bin/cvsweb.cgi/~checkout~gnus/texi/gnus-coding.texi?rev=HEAD&content-type=text/plain
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Ways of keeping Emacs 22 and external projects in sync

[Giorgos Keramidas]

On 2007-01-01 16:21, Ralf Angeli <angeli@caeruleus.net> wrote:
> * Michael Olson (2007-01-01) writes:
> > When there are some changes that need to be propagated to Emacs 22, I
>
> So you are updating ERC in Emacs not on a release-by-release basis,
> but rather when some important changes need to be propagated?  Do you
> apply a tag in that case in order to identify the file revisions if
> somebody has a bug report or support request referring to the ERC
> version in Emacs or do you just use the files in Emacs directly for
> testing and debugging?

Arch is a distributed SCM, and it can keep track of what changes have
been merged.  Michael mentioned that he keeps various Arch branches for
synchronizing the ERC tree with Emacs:

    erc--main--0 :: Where development happens

    erc--rel--5.1 :: Where the currently previous major release (5.1)
      gets updated when it is time to prepare a minor release.

    erc--emacs--22 :: The branch which is used to sync to and from the
      version in Emacs 22.

Merging changesets from one Arch branch to another one is easy.  Arch
keeps track of the changesets you have merged from erc--main--0 into
erc--emacs--22.

>> first check emacs--devo--0 to see if someone changed things on the
>> Emacs side, by running ./scripts/sync-from-emacs.  If anything is
>> different than the current contents of erc--emacs--22, I immediately
>> check them in (to erc--emacs--22).
>
> Do you regularly synch from Emacs or just when you are about to synch
> to Emacs?
>
> My idea for RefTeX would have been that a synch from Emacs to RefTeX
> is done regulary, but directly instead of using an intermediate
> repository.

In distributed SCM's a "branch" is, effectively, a "repository".  For
example, for my own Emacs stuff, I keep the following "branches" around,
with Mercurial (another distributed SCM):

    emacs/gnu
    emacs/keramida

Changes are automatically pulled into emacs/gnu, from a cron job, using
a conversion script which pulls over changesets from CVS.

I keep working in emacs/keramida, making my own changes.

Whenever I want to 'resync' with the official Emacs repository, I pull
changes from emacs/gnu into emacs/keramida and merge locally, inside the
emacs/keramida repository-branch.

After a merge, I can diff with emacs/gnu and post patches to the
official Emacs source tree.

My own suggestion, which pretty much matches what Michael and Miles do
with Arch, is that you *do* keep intermediate merge-branches in your own
repository, whatever the SCM you use will be :)

Re: Ways of keeping Emacs 22 and external projects in sync

[Yavor Doganov]

В Mon, 01 Jan 2007 16:21:18 +0100, Ralf Angeli написа:
>
> As Savannah supports Arch repositories now it should be no problem to
> maintain RefTeX in such a repository.  What I would be missing with
> Arch would be something like PCL-CVS [...]

There is xtla-el (https://gna.org/projects/xtla-el), which is an Emacs
interface to GNU Arch.  I haven't used it (yet), but people say it's quite
good.

Re: Ways of keeping Emacs 22 and external projects in sync

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]

Yavor Doganov <yavor@doganov.org> writes:

> В Mon, 01 Jan 2007 16:21:18 +0100, Ralf Angeli написа:
>>
>> As Savannah supports Arch repositories now it should be no problem to
>> maintain RefTeX in such a repository.  What I would be missing with
>> Arch would be something like PCL-CVS [...]
>
> There is xtla-el (https://gna.org/projects/xtla-el), which is an Emacs
> interface to GNU Arch.  I haven't used it (yet), but people say it's quite
> good.

Xtla has now evolved into DVC.  DVC is getting fairly stable, and
supports other distributed revision control systems (particularly bzr
and Mercurial) in addition to Arch.

URL: http://download.gna.org/dvc/

The Arch component of DVC is just as complete as the last release of
Xtla.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Ways of keeping Emacs 22 and external projects in sync

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 5447 bytes --]

Ralf Angeli <angeli@caeruleus.net> writes:

>> sync-to-emacs:
>> ===
>> #!/bin/bash
>>
>> # Load common definitions
>> . scripts/common.defs
>>
>> (cd $LISP/erc && find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $OLDPWD \;)
>> cp $ETC/ERC-NEWS etc/
>> cp $MAN/erc.texi man/
>> rm -f *.elc
>> ===
>
> The scripts look identical.  Is that correct?

Sorry about that.  It should have been:

sync-to-emacs:
===
#!/bin/bash

# Load common definitions
. scripts/common.defs

find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $LISP/erc \;
find ./etc -maxdepth 1 -mindepth 1 -type f -exec cp {} $ETC \;
find ./man -maxdepth 1 -mindepth 1 -type f -exec cp {} $MAN \;
===

Sorry about that.

>> When there are some changes that need to be propagated to Emacs 22, I
>
> So you are updating ERC in Emacs not on a release-by-release basis,
> but rather when some important changes need to be propagated?

Yes.  Of course, it's a priority to merge releases to Emacs 22.

> Do you apply a tag in that case in order to identify the file
> revisions if somebody has a bug report or support request referring
> to the ERC version in Emacs or do you just use the files in Emacs
> directly for testing and debugging?

No.  I can get changes for any revision that I commit at any time, so
there isn't a need for making tags.  I use DVC
(http://download.gna.org/dvc/) to easily fetch changes: it gives me a
listing of patches that I've committed, and I only need to hit "=" to
view the one at point in diff form.

I usually do debugging in the erc--main branch, because the versions
are consistent enough that problems should be replicable there.  If
needed, I could easily just remove the (add-to-list 'load-path ...)
line for ERC from my config, and work in Emacs directly, calling
sync-from-emacs when I've fixed the problem (to propagate to
erc--emacs--22), and so on.

>> first check emacs--devo--0 to see if someone changed things on the
>> Emacs side, by running ./scripts/sync-from-emacs.  If anything is
>> different than the current contents of erc--emacs--22, I immediately
>> check them in (to erc--emacs--22).
>
> Do you regularly synch from Emacs or just when you are about to
> synch to Emacs?

Usually I only do it when I'm about to sync to Emacs.  I also do it
whenever I run "tla update" on Emacs 22 (about once a month), if I
notice that some ERC files were modified.

> My idea for RefTeX would have been that a synch from Emacs to RefTeX
> is done regulary, but directly instead of using an intermediate
> repository.

That would work, too.

>> I also think it is a very bad idea for Emacs developers to mandate
>> checking in files individually.  It might make sense for work on the
>> core files in lisp/emacs-lisp/ or the top-level of lisp/, but a
>> significant percentage of changes made to the other lisp files involve
>> changing several files at once.  Separating log entries for commit
>> messages begins to become a burden.  For operations such as updating
>> an entire project, this would become very tedious (not to mention
>> unnecessary, because ChangeLog contains all the information that is
>> really needed).
>
> That reminds me: When you are synching from Emacs to ERC (and vice
> versa) the ChangeLog file is probably handled the same way Lisp files
> are.  Because log entries of changes to RefTeX in Emacs currently end
> up in lisp/ChangeLog we'd need a separate ChangeLog file for RefTeX
> for this to work.

That would be trickier.  I assumed RefTeX would be getting its own
subdirectory in lisp/.  You might have to keep a separate ChangeLog
and manually copy over ChangeLog entries when syncing to Emacs 22.

>> With Arch, such changes are treated as a single change to the entire
>> project, rather than multiple separate changes to single files.  There
>> is no possibility (however remote) of changes to several files being
>> only partially applied, as long as Arch is the only version control
>> system involved.
>
> As Savannah supports Arch repositories now it should be no problem to
> maintain RefTeX in such a repository.  What I would be missing with
> Arch would be something like PCL-CVS and the web interface like
> Savannah provides it for CVS repositories.

I don't really know what PCL-CVS is used for, but DVC (link given
above) satisfies me.  It really brings out Arch's potential.

As for a web interface, I set up one on my own webserver, and edited
Savannah's configuration for ERC to point to it.  Link is:
http://www.mwolson.org/cgi-bin/archzoom/archzoom.cgi/erc@sv.gnu.org

For safety's sake (to keep from getting close to my disk space quota),
I have a cron job on my webserver that removes the generated
changesets and such once a week.  This assumes that ArchZoom has
temp_dir = /home/mwolson/tmp.

remove-tmp:
===
#!/bin/sh
# Remove ArchZoom cruft

PRE=/home/mwolson

[ -d $PRE/,,tmp ] && exit 0 || :
[ -d $PRE/tmp ] || exit 0
mv /home/mwolson/tmp /home/mwolson/,,tmp
mkdir $PRE/tmp
rm -fr $PRE/,,tmp
===

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Re: Ways of keeping Emacs 22 and external projects in sync

[Ralf Angeli]

* Michael Olson (2007-01-03) writes:

[Lots of useful stuff]

Thanks very much for this information!

-- 
Ralf

Re: Ways of keeping Emacs 22 and external projects in sync

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 1662 bytes --]

Michael Olson <mwolson@gnu.org> writes:

>> Do you apply a tag in that case in order to identify the file
>> revisions if somebody has a bug report or support request referring
>> to the ERC version in Emacs or do you just use the files in Emacs
>> directly for testing and debugging?
>
> No.  I can get changes for any revision that I commit at any time, so
> there isn't a need for making tags.  I use DVC
> (http://download.gna.org/dvc/) to easily fetch changes: it gives me a
> listing of patches that I've committed, and I only need to hit "=" to
> view the one at point in diff form.
>
> I usually do debugging in the erc--main branch, because the versions
> are consistent enough that problems should be replicable there.  If
> needed, I could easily just remove the (add-to-list 'load-path ...)
> line for ERC from my config, and work in Emacs directly, calling
> sync-from-emacs when I've fixed the problem (to propagate to
> erc--emacs--22), and so on.

Additionally, I should add that I keep a checkout of each branch in
its own directory.  For example: erc/emacs22 (erc--emacs--22),
erc/arch (erc--main--0), erc/arch-5.1 (erc--rel--5.1).  This makes it
very easy to do sanity checks (diff -u against two directories) to
make sure that every desired change has been merged.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Ways of keeping Emacs 22 and external projects in sync (was: CVS repository synchronization for RefTeX)

[Giorgos Keramidas]

On 2007-01-01 02:09, Michael Olson <mwolson@gnu.org> wrote:
>Ralf Angeli <angeli@caeruleus.net> writes:
>> * Giorgos Keramidas (2006-12-31) writes:
>>> The people who currently maintain cc-mode and Gnus may have useful
>>> feedback, regarding the tools they use for the job.  [...]
>>
>> Well, I was hoping for some of them to chip into this thread.
> 
> I guess I'll chip in with how I manage to keep the development version
> of ERC synced with that included with Emacs 22.  [...]

Thank you!  This is *exactly* the sort of response I was hoping to
trigger and was asking for :)

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

    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.

Making such branches is ok with me.

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

    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.

    What about branching?  IIUC CVS branches can only be created for a
    whole module.  Would it be okay to create a branch for all of Emacs if
    one for RefTeX only were necessary?

Yes, it is ok.

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Richard Stallman (2006-12-30) writes:

>     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.

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.  Thus, in Emacs there there would be releasable code
of the package at any time.  With such a policy I would not expect the
difficulty you mentioned to appear.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

    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.  Thus, in Emacs there there would be releasable code
    of the package at any time.

In theory, this is good.  But what often happens is that people
develop a package on its own, and we have trouble getting the changes
into Emacs.

Right now there are fixes in CC mode which have not been installed
in Emacs, and that is one of the things our release is waiting for.

Re: CVS repository synchronization for RefTeX

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     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.  Thus, in Emacs there there would be releasable code
>     of the package at any time.
>
> In theory, this is good.  But what often happens is that people
> develop a package on its own, and we have trouble getting the changes
> into Emacs.
>
> Right now there are fixes in CC mode which have not been installed
> in Emacs, and that is one of the things our release is waiting for.

Uh, I don't see why having CC mode in Emacs would make this easier:
the whole point of the uninstalled fixes is that they are fixes to a
comparatively _stable_ version fit for release with Emacs 22.  The
HEAD of CC mode is _much_ less suited to be released with Emacs 22 if
I have understood things correctly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

      The
    HEAD of CC mode is _much_ less suited to be released with Emacs 22 if
    I have understood things correctly.

When packages are maintained inside Emacs, people work on development
somewhat differently, implementing improvements with an eye towards
releasing them in the next Emacs release.

Re: CVS repository synchronization for RefTeX

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       The
>     HEAD of CC mode is _much_ less suited to be released with Emacs 22 if
>     I have understood things correctly.
>
> When packages are maintained inside Emacs, people work on development
> somewhat differently, implementing improvements with an eye towards
> releasing them in the next Emacs release.

Uh, reality check.  The situation with RefTeX is that nobody works on
it any which way except Carsten, and he is passing on the buck because
he no longer has time for it.

So the current situation is that RefTeX is not maintained, whether in
Emacs or outside of it, and that is what we have to start with.  Now
the question is where we can hope to get the most attention for it.

In the Emacs repository, we have a tex-mode.el that gets very little
attention from Emacs developers.  Mainly Stefan Monnier if I am not
mistaken.  If one takes a look at who did changes to RefTeX in the
past, it is very basically a one-man show, more so than tex-mode.el.

RefTeX's approach is an "all-around" one, similar to AUCTeX's.  At the
current point of time, RefTeX can only be used for LaTeX, and there
are very few people actually writing LaTeX in Emacs without using
AUCTeX.  Those that prefer using the minimal tex-mode.el are not
usually the kind of people that use comprehensive tools like RefTeX (I
seem to remember that Carsten did not know of anybody using RefTeX at
the current point of time with tex-mode.el or other LaTeX modes).

RefTeX even has its own section in the AUCTeX quick reference sheets,
and there are a few references to it in the AUCTeX manual.

Ultimately, I hope that the point will become mostly moot by AUCTeX
being folded into Emacs.  However, I still think a separate repository
like with Gnus makes sense, and the time frame for folding AUCTeX into
Emacs will probably be still years because of copyright paper reasons
(we are progressing there, but not really fast).

It is my opinion that the chances of RefTeX getting more development
done on will be better with RefTeX in the AUCTeX repository rather
than Emacs.  So I'd definitely prefer a solution where the Emacs CVS
contained mostly a variant of RefTeX intended for release with Emacs
only.

Having the RefTeX infrastructure scattered across the Emacs CVS
repository will rather get us fewer developers willing to actively
touch it than even the current situation.

I mean, let us just ask: are there any Emacs developers listening who
can imagine themselves working on RefTeX?  If so, would they think
using the Emacs CVS more convenient for them than the AUCTeX
repository?

Of those who would consider working on RefTeX, how many have an
assignment and/or CVS write access for Emacs, and how many for AUCTeX?

-- 
David Kastrup

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

    I mean, let us just ask: are there any Emacs developers listening who
    can imagine themselves working on RefTeX?

I am not sure why that question is relevant.  We may have a shortage
of people who would want to maintain RefTeX, but that isn't a matter
of where the repository is.

Given that RefTeX has a separate repository already, I don't think
there is any harm in moving it, as such.  (I already said so.)

However, moving it into the AUCTeX repository creates a possible
specific risk.  Namely, the risk that AUCTeX contributors who have not
signed papers might put changes into RefTeX also.

    the time frame for folding AUCTeX into
    Emacs will probably be still years because of copyright paper reasons
    (we are progressing there, but not really fast).

Are there any current contributors to AUCTeX who have not yet signed
papers for Emacs (which would include RefTeX)?

Re: CVS repository synchronization for RefTeX

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I mean, let us just ask: are there any Emacs developers
>     listening who can imagine themselves working on RefTeX?
>
> I am not sure why that question is relevant.  We may have a shortage
> of people who would want to maintain RefTeX, but that isn't a matter
> of where the repository is.
>
> Given that RefTeX has a separate repository already, I don't think
> there is any harm in moving it, as such.  (I already said so.)

It hasn't: Carsten has worked on it basically without version control
or at least version logs at home.  He considered the history in the
Emacs ChangeLog to be much more relevant than what he got himself.

> However, moving it into the AUCTeX repository creates a possible
> specific risk.  Namely, the risk that AUCTeX contributors who have not
> signed papers might put changes into RefTeX also.

No, that risk does not exist.  We don't give CVS access to AUCTeX
developers not having signed papers.  The assignment problems of
AUCTeX only concern old code, and not all of it (for example,
preview-latex, a subsystem of AUCTeX, is completely covered).

>     the time frame for folding AUCTeX into Emacs will probably be
>     still years because of copyright paper reasons (we are
>     progressing there, but not really fast).
>
> Are there any current contributors to AUCTeX who have not yet signed
> papers for Emacs (which would include RefTeX)?

No.  It is only old contributors, and we covered all of the principal
ones.  The rest may be a lot of work, but the actual amounts of code
concerned are not too extensive as far as I can see.

-- 
David Kastrup

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

    > However, moving it into the AUCTeX repository creates a possible
    > specific risk.  Namely, the risk that AUCTeX contributors who have not
    > signed papers might put changes into RefTeX also.

    No, that risk does not exist.  We don't give CVS access to AUCTeX
    developers not having signed papers.  The assignment problems of
    AUCTeX only concern old code, and not all of it (for example,
    preview-latex, a subsystem of AUCTeX, is completely covered).

Ok, I am satisfied on this score.

    > Given that RefTeX has a separate repository already, I don't think
    > there is any harm in moving it, as such.  (I already said so.)

    It hasn't: Carsten has worked on it basically without version control
    or at least version logs at home.  He considered the history in the
    Emacs ChangeLog to be much more relevant than what he got himself.

In that case, I think this will be, to a certain extent, a step back.
But we can live with it.

So we can drop this topic.

Re: CVS repository synchronization for RefTeX

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > However, moving it into the AUCTeX repository creates a possible
>     > specific risk.  Namely, the risk that AUCTeX contributors who have not
>     > signed papers might put changes into RefTeX also.
>
>     No, that risk does not exist.  We don't give CVS access to AUCTeX
>     developers not having signed papers.  The assignment problems of
>     AUCTeX only concern old code, and not all of it (for example,
>     preview-latex, a subsystem of AUCTeX, is completely covered).
>
> Ok, I am satisfied on this score.
>
>     > Given that RefTeX has a separate repository already, I don't think
>     > there is any harm in moving it, as such.  (I already said so.)
>
>     It hasn't: Carsten has worked on it basically without version control
>     or at least version logs at home.  He considered the history in the
>     Emacs ChangeLog to be much more relevant than what he got himself.
>
> In that case, I think this will be, to a certain extent, a step back.
> But we can live with it.

Uh, we can live with what exactly?

> So we can drop this topic.

The topic was whether it would be ok to have Carsten Dominik pass on
maintenance of refTeX basically to the AUCTeX team and have RefTeX's
primary CVS moved as a module to AUCTeX CVS, while keeping the update
process of Emacs' builtin RefTeX as it currently is (namely refreshing
the CVS with stable changes and fixes while Emacs is in freeze).

While I tend to interpret your mail as you being ok with that
approach, I don't find that interpretation sufficiently unambiguous to
be sure.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

    Uh, we can live with what exactly?

Maintaining RefTeX in the AUXTeX repository,
as was proposed.

Re: CVS repository synchronization for RefTeX

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Uh, we can live with what exactly?
>
> Maintaining RefTeX in the AUXTeX repository,
> as was proposed.

Thanks.  I really think that this is the way best for future RefTeX
development.

Further discussion to auctex-devel.  We will need to ask some savannah
hacker to make a copy of the Emacs CVS into an AUCTeX module, and then
we'll need to check in the additional files from Carsten.

And then we will have to fix refTeX to make it work with AUCTeX's
docTeX-mode...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS repository synchronization for RefTeX

[Reiner Steib]

On Sat, Dec 30 2006, Ralf Angeli wrote:

> * Stefan Monnier (2006-12-29) writes:
>
>>> maintenance of RefTeX will likely be continued by the AUCTeX project.
>>> On the AUCTeX developers list it is currently being discussed how
>>> maintenance of RefTeX will be done in its own CVS repository.
>>
>> How 'bout using the Emacs-CVS as *the* repository of RefTeX?
>
> There will be standalone releases of RefTeX.  That means files for
> building and installing RefTeX as well as files like README, INSTALL,
> etc. would have to be added to Emacs' repository.  Those would mostly
> be superfluous in an Emacs release and would have to be excluded from
> pretest and release tarballs, unless they are considered only a minor
> annoyance.

Maybe we could use admin/reftex/* for such files.  (admin/ is excluded
from the tar ball anyhow, CMIIW.)

> And we'll probably have to jump through some hoops for building
> documentation and putting it into a RefTeX tarball as reftex.texi
> currently is located in the man directory.

When using admin/reftex/*, I don't see that it's much harder than in a
separate repository.

With Richard's okay to a RefTeX-only branch in Emacs CVS, this sounds
like a good solution to me.  The branch would be e.g. "reftex_devel"
and the Emacs trunk would correspond to the current stable RefTeX
branch.  Keeping both in the same CVS repository would also make it
easier to merge bugfixes and administrative changes (update of
copyright notices, etc.) from Emacs trunk to "reftex_devel" much
easier (maybe Miles could do this like he does with the unicode branch
and other branches).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Reiner Steib (2006-12-30) writes:

> Maybe we could use admin/reftex/* for such files.  (admin/ is excluded
> from the tar ball anyhow, CMIIW.)
>
>> And we'll probably have to jump through some hoops for building
>> documentation and putting it into a RefTeX tarball as reftex.texi
>> currently is located in the man directory.
>
> When using admin/reftex/*, I don't see that it's much harder than in a
> separate repository.

I'm not sure if I understood correctly.  You mean to put only the
build files, auxiliary files (README, INSTALL, etc.) and ChangeLog
into admin/reftex?

> With Richard's okay to a RefTeX-only branch in Emacs CVS, this sounds
> like a good solution to me.

What I dislike about it is that the files will be scattered throughout
Emacs' repository.  This makes fetching the "package" RefTeX from CVS
much more complicated.  And with the branch it would get even harder
if people want to fetch a development version.  Also stuff like `C-x 4
a' won't work with such a file layout and a single ChangeLog file.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Reiner Steib]

On Sun, Dec 31 2006, Ralf Angeli wrote:

> * Reiner Steib (2006-12-30) writes:
>> When using admin/reftex/*, I don't see that it's much harder than in a
>> separate repository.
>
> I'm not sure if I understood correctly.  You mean to put only the
> build files, auxiliary files (README, INSTALL, etc.) and ChangeLog
> into admin/reftex?

Yes.  (WRT ChangeLog, see below.)

>> With Richard's okay to a RefTeX-only branch in Emacs CVS, this sounds
>> like a good solution to me.
>
> What I dislike about it is that the files will be scattered throughout
> Emacs' repository.  This makes fetching the "package" RefTeX from CVS
> much more complicated.  And with the branch it would get even harder
> if people want to fetch a development version.  

If I understand Stefan correctly, it's possible to create a branch
with just the RefTeX relevant files.  So it should be possible to "cvs
co -t reftex_devel ...", i.e. only check out RefTeX relevant files
from Emacs CVS.  If not with this command, it should be simple to make
such a target in admin/reftex/Makefile nevertheless (cvs [...] co
emacs/admin/reftex/ && cd emacs/admin/reftex/ && make fetch-files).

> Also stuff like `C-x 4 a' won't work with such a file layout and a
> single ChangeLog file.

A the changes would be done in the Emacs CVS directory layout, also
these ChangeLog files (lisp/ChangeLog, man/ChangeLog) should be used.
No problem with `C-x 4 a'.

I played a bit with the following[1] sketch of admin/reftex/Makefile.
Using grep-changelog we can build RefTeX-only ChangeLog files (some
entries are not extracted correctly, but this could be remediated by
re-writing the corresponding entries in the original ChangeLog files
(or improving grep-changelog?).

Bye, Reiner.

[1]
--8<---------------cut here---------------start------------->8---
base=../..
grepcl=$(base)/lib-src/grep-changelog --text=reftex

ChangeLogs:	lisp/ChangeLog texi/ChangeLog


lisp/ChangeLog:	$(base)/lisp/ChangeLog
	$(grepcl) $< | sed -e 's,textmodes/reftex,reftex,g' > $@

texi/ChangeLog:	$(base)/man/ChangeLog
	$(grepcl) $< > $@

clone-files:
	cp -p $(base)/lisp/textmodes/reftex*.el lisp/
	cp -p $(base)/man/reftex.texi texi/

clean:
	rm lisp/ChangeLog texi/ChangeLog
--8<---------------cut here---------------end--------------->8---
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: CVS repository synchronization for RefTeX

[Ralf Angeli]

* Reiner Steib (2007-01-01) writes:

> On Sun, Dec 31 2006, Ralf Angeli wrote:
>
>> What I dislike about it is that the files will be scattered throughout
>> Emacs' repository.  This makes fetching the "package" RefTeX from CVS
>> much more complicated.  And with the branch it would get even harder
>> if people want to fetch a development version.  
>
> If I understand Stefan correctly, it's possible to create a branch
> with just the RefTeX relevant files.

I have yet to find documentation of such a feature.  The only thing
I've found was a usenet post warning not to branch selected files
only, because CVS gets confused when updating or commiting in a
directory containing branched and non-branched files.  Such a mix
might not happen with the setup proposed by Stefan, however.

>> Also stuff like `C-x 4 a' won't work with such a file layout and a
>> single ChangeLog file.
>
> A the changes would be done in the Emacs CVS directory layout, also
> these ChangeLog files (lisp/ChangeLog, man/ChangeLog) should be used.
> No problem with `C-x 4 a'.

And what about standalone releases?  Would those be shipped with
ChangeLog files for each directory?  We'd probably have to clean those
files in the branch of any entries not related to RefTeX.

> I played a bit with the following[1] sketch of admin/reftex/Makefile.
> Using grep-changelog we can build RefTeX-only ChangeLog files

Okay, that would be another approach.

I still cannot say that I am too enthusiastic about maintaining a
package when its files are scattered throughout a larger repository.

-- 
Ralf

Re: CVS repository synchronization for RefTeX

[Stefan Monnier]

> There will be standalone releases of RefTeX.  That means files for
> building and installing RefTeX as well as files like README, INSTALL,
> etc. would have to be added to Emacs' repository.

Those can easily be put into the `admin' subdirectory which is not included
in Emacs releases.

> And we'll probably have to jump through some hoops for building
> documentation and putting it into a RefTeX tarball as reftex.texi
> currently is located in the man directory.

Right, you'd have to do a bit of extra work to bring the various files from
`admin', `man', `lisp', ... into a single directory when building
the tarball.

> Then there might be the problem that RefTeX is not in a releasable
> state at the time an Emacs release is about to happen.  Suppose I
> would have had a major and risky change for RefTeX waiting to be
> checked in about a year ago and held it back because Emacs is about to
> be released.  I'd probably still not have it checked in.  Such a
> situation nothing I'd be looking forward to.  Of course in an urgent
> case one can back out such changes, but if you can avoid it ...

That's what branches are for.  No problem here.

> What about branching?  IIUC CVS branches can only be created for a
> whole module.

You understand incorrectly.  In CVS each file is handled separately (so to
a large extent, the notion of "module" only exists in the documentation of
CVS rather than in its code and behavior), so you can have separate branches
on a file-by-file basis.  It's generally saner to have the same branches on
"every" file, but it's perfectly OK to have a branch only on a well-defined
subset of the files, such as have a RefTeX-only branch on the
RefTeX-related files.

> Would it be okay to create a branch for all of Emacs if
> one for RefTeX only were necessary?

That would be OK as well, although not needed.

> If RefTeX is to be maintained in Emacs' repository I'd actually like
> to have all files (including documentation) in one dedicated
> directory.

That would probably not be an option.  Although, starting from the Arch
version of Emacs's repository, you could easily create an Arch archive for
RefTeX which automatically tracks all the RefTeX files (and only them), and
placed in a single directory or any other way you want.


        Stefan

Re: CVS repository synchronization for RefTeX

[Richard Stallman]

I would rather have the maintenance of RefTeX done in the Emacs repository.

Re: CVS repository synchronization for RefTeX

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I would rather have the maintenance of RefTeX done in the Emacs
> repository.

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.

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.

RefTeX also is maintained for XEmacs.  What we have in Emacs is just a
fraction of the whole of RefTeX.

I don't think that maintaining the whole in the Emacs repository is
likely to lead to the best results, since RefTeX is not released just
for Emacs, and even should work with more than one Emacs version.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS repository synchronization for RefTeX

[Bill Wohler]

Ralf Angeli <angeli@caeruleus.net> writes:

> How do other projects with repositories outside of Emacs, like
> CC mode or MH-E, handle this?

Hi Ralf,

I moved the MH-E repository from SourceForge to Savannah a year or two
ago reluctantly, and it has simplified maintenance a lot by
eliminating the merge process, even though it was largely automated.

It was not a problem getting the requisite papers from the MH-E
developers.

While Emacs is not in pretest, it is not a problem to develop and
release your package at any time. We have our own version
(mh-version), our own tags (try cvs stat -v lisp/mh-e/mh-e.el), and I
recently added a :package-version keyword to defcustom so that you can
track the changes to your options in the various versions of your
package.

I would have preferred that a branch were created by the Emacs
developers once the code was frozen for the first pretest so that we
could continue to develop MH-E on the trunk. The rationale is that
there is a lot more development on the trunk than on the pretest
branch, and therefore merging from a branched pretest to the trunk is
a lot easier than vice-versa. A branch also protects the pretest from
unnecessary check-ins. But, until that happens, we can fairly easily
create a branch ourselves and merge back to the trunk once Emacs is
released.

In short, I'm much happier using the Emacs repository at Savannah.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

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

[Ralf Angeli]

* Bill Wohler (2007-01-07) writes:

> I would have preferred that a branch were created by the Emacs
> developers once the code was frozen for the first pretest so that we
> could continue to develop MH-E on the trunk.

Thanks very much for sharing your experience.  Nevertheless, given
what you've written above I think we've made the right decision to
maintain RefTeX in a separate repository.

-- 
Ralf