auctex-devel
[Top][All Lists]
Advanced

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

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


From: David Kastrup
Subject: Re: [AUCTeX-devel] Re: CVS repository synchronization for RefTeX
Date: Sun, 07 Jan 2007 13:19:05 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2007-01-07) writes:
>
>> Ralf Angeli <address@hidden> writes:
>>
>>> I am more worried about propagating changes _from_ Emacs.  The
>>> changes propagating to Emacs will mostly be check-ins of new RefTeX
>>> version which should be possible to be handled easily.  I'm not so
>>> sure if this is similar in the case of changes done in the Emacs
>>> repository which are to be included in the RefTeX repository.
>>
>> Ralf, you are basically arguing for taking over RefTeX maintenance
>> yourself, using Arch, and not in connection with AUCTeX.
>
> No, I'm not.  Savannah features support for public Arch archives
> which could be used similarly to CVS.  Thus, all developers could
> participate just like the do with CVS now.

My proposal was about moving RefTeX into AUCTeX's repository.  Not
about creating a different repository on Savannah where things would
be maintained independently.

You are now proposing something different.

>>>> Because I don't want to restrict RefTeX developers and pretesters
>>>> to just people installing the newest Emacs versions.
>>>
>>> Regarding developers, AFAICT DVC is compatible with Emacs 21.
>>
>> What does "is compatible" mean?
>
> Can be used with Emacs 21.

I don't want to reply on version control systems for AUCTeX that don't
work out of the box with Emacs versions that can be reasonably
expected to be used by testers/developers.  It is an additional
hurdle.

>> What is "DVC"?
>
> An Arch interface for Emacs, see <URL:http://download.gna.org/dvc/>.
>
>> What does "regarding
>> developers" mean?
>
> You were mentioning developers and pretesters, and the use of an
> Emacs interface for versioning control will more likely be relevant
> for developers.  I wanted to contrast that.

I don't agree.  Certainly pretesters of Emacs packages are not
unlikely to use Emacs for version control.

>>>> If we provide RefTeX also for older versions, we certainly don't
>>>> want to exclude people willing to test those versions.
>>>
>>> But why would those people get the sources through Emacs anyway?
>>
>> Why wouldn't they?
>
> Because instructions for getting sources usually refer to the
> standalone programs.  In fact, I don't even know how to do a fresh
> checkout of a CVS archive through Emacs.

We are talking about continuous work, and there Emacs is a lot of
help.

> But that might just be the cause of me not looking hard enough for
> instructions.  Updating a working directory through Emacs is
> probably a more relevant use case for pretesters, but one which
> could easily be solved as well by using the client binary for the
> version control system.

Ralf, we are not talking about keeping a bunch of dedicated developers
by having them jump only through a moderate number of hoops.

At the current point of time, you have not even played with Arch at
all, yet you propose putting all of RefTeX under it and not put it in
AUCTeX.

This discussion is not going anywhere at this point of time.  If you
say that you want any possible action postponed until you feel you
have been able to evaluate the alternatives, this is reasonable.

But at the current point of time you are arguing for putting RefTeX
outside of AUCTeX into a version control system that nobody who could
expect to work on RefTeX has used or evaluated up to now.

I think RefTeX deserves to get a place where further development on it
seems likely and feasible.  And I don't see that your proposals lead
there.

If you think that RefTeX does not belong in an AUCTeX module and make
a good case for that, we might reconsider the offer.  But "Arch
exists" without any personal experience is not what I would want to
base such a step on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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