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 14:38:37 +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, 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.
>
> Could you please be more specific?  Do you mean to create a new
> module at the same level as the `auctex' module or do you meant to
> put RefTeX into its own folder below `auctex'?

We were not through discussing the details of that before you diverted
the discussion to Arch.

>> Not about creating a different repository on Savannah where things
>> would be maintained independently.
>>
>> You are now proposing something different.
>
> Assuming we give RefTeX its own module in CVS I don't see much of a
> difference between that and giving RefTeX its own Arch repository.
> With the CVS approach you'll need a separate check-out as well.
> It's not like a `cvs up' in the `auctex' folder will spew out
> RefTeX.

One does not need a separate account, one does not need to register
access for a different project, one does not need to change the tools
one uses.

For me, that is "much of a difference".

>>> 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.
>
> It's a one-time effort which could spare you a lot of work in the
> long run.  But I'm repeating myself.

We are talking about what will ensure people's participation.  Miles
apparently synchronizes CVS archives with little effort for a much
larger and much more active project, Gnus.  That he does this using
Arch as an inbetween tool does not affect the developers using the CVS
archives.

And I don't think that we would update RefTeX in the Emacs tree as
often as Gnus gets updated/fixed.

>>> 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.
>
> No, I'm not!  I think I made it clear that I first want to look more
> closely at Arch in order to make an informed decision.

The decision you talk about implies making RefTeX a project that is
kept completely separate from AUCTeX.  And if I considered that the
best course, I would not have made the proposal to take over
responsibility for RefTeX in the first place.

> I just want to prevent a premature decision towards CVS.

There is no "premature decision towards CVS" involved here at all.
What is involved is a decision towards moving RefTeX into the AUCTeX
development context, and this automatically means "CVS" as long as
this remains the version control system used for AUCTeX.

Of course, version control issues might well mean that we want to keep
AUCTeX and RefTeX separate.  But I would not have proposed taking over
RefTeX maintenance if I had thought this likely when taking into
account everything.

> The stuff I've already learned about Arch just gave me a bit of
> cannon fodder I could use in the discussion.  That's all.

I would prefer if you simply said you need more time in order to feel
able to converge with the other developers to a good decision rather
than tying up both your as well as others' time into a "cannon fodder"
discussion.

>> This discussion is not going anywhere at this point of time.
>
> Right.  I'm glad you articulated this because I've come to the same
> conclusion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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