Re: issues with arch? Re: [Fenfire-dev] PEG: tla fixed

[Tuomas Lukka]

On Fri, Oct 03, 2003 at 04:38:40PM +0300, Alatalo Toni wrote:
> On Tue, 16 Sep 2003, Tuomas Lukka wrote:
> 
> two things, issues?
> 
> > Issues
> > ======
> > - Should **everything** be done in arch?
> >    RESOLVED: No. Some things are more hassle than necessary there.
> >    ``manuscripts`` and ``spaces`` shall still be primarily
> >    handled through CVS, and mirrored to arch.
> 
> 1. anon. access: will cvs be kept in synch and the way for
>    'outsiders' to get a hold, or arch used also for that?
> 
>    Tuukkah already set up http access at
>    http://himalia.it.jyu.fi/%7barchives%7d/
>    but i had no luck retrieving from there (misses .listing)

There's a workaround to the problem that tla only allows this to be
set at creation explained in response to my bug report about 
this:

        http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5241&group_id=4899

> 2. branching: <mudyc> felt that arch is making working difficult,
>    that the idea of everyone having separate branches is flawed
>    when we are working on a common target.
>    what are the problems actually and could some utils or
>    practices solve them perhaps?

Yes, I discussed this with Benja yesterday: it's true that some sense
of community has been lost - it's not as easy to keep track of what
others are doing. 

What mudyc and jvk suggest in the other mail are excellent suggestions;
I say we try them.  Tuukkah: could you adjust archbot accordingly?

However, re: branching I do disagree. The point is that 
you should make a branch when doing a large change that may not be finished
at once.

Such as my recursive vobscene -stuff, which first breaks some things and
only when it works fixes them.

One important thing to understand is that the idea is not to keep branches 
around
but just quickly

        1) create a branch
        2) do your stuff
        3) ask for merge.
        4) discard branch

The point is that you get to offer your changes when you feel they're ready.

But it's obvious we need to further discuss this; having several developers
unhappy with the system we use is not good.

        Tuomas