axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] sourceforge/silver


From: Page, Bill
Subject: RE: [Axiom-developer] sourceforge/silver
Date: Fri, 27 Oct 2006 15:57:43 -0400

Tim, 

On Friday, October 27, 2006 1:56 PM you wrote:
> Gaby wrote: 
> > What you want is not to merge branch-improvements back to
> > trunk at this moment.  Rather, you want to minimize distance
> > as much as possible.  Concretely, that means backporting
> > some patches on silver to that branch -- not the other way
> > around.
> 

Here is how I see the situation:

            |       |            |           |
            |       |        darcs and       |
            |    next big =  hg mirrors      |
            |    experiment      |           |
 gold       |   /                            |
 gold <---- |  /                             |
 (52)     silver  (SourceForge) <=====> Google Code
            |                             mirror
            |\___merge___                    |
 gold <---- |            \        |          |
 (51)       |\__          |       |          |
           /    \   back  |   darcs and      |
 gold <---|-<----\ .....> / = hg mirrors     |
 (50)     /      /  port |        |          |
         |      |        |        |          |
Now:   silver trunk    build
         |      |   improvements
        tla     |    /
                |   /
                |  /
 gold <------ trunk
 (49)           |
               CVS


What Gaby is talking about is shown as ....> above.

Now is that really *so* complicated?? :-)

> merging build-improvements can happen "when it is ready"
> and i suspect it will take a fair amount of give-and-take
> about things like documentation and philosophy. but i'm
> not suggesting we start that now.
> 
> other than the autotools items, it is in our best interest
> to make axiom--silver--1 and build-improvements identical. 
>

For me personally, autoconf support is more important than
almost everything else, the reason being that I would really
like to see more Axiom developers. The more standard our build
environment is, the easier that will be. Seconly increasing
the number of type of supported platforms is very important
for increasing the number of Axiom users.

So I am especially interested in what I labelled Gold (52)
above, but I can live with the experimental branch until
then.

> so the point of the discussion was that when we make changes
> they ought to go into the silver branch (which is the next
> world release) if they can. and the agreed-upon mechanism is
> to post diff patches against Gold to the mailing list. i don't
> see this happening and it concerns me.
> 

Diffing patches against Gold seems problematic to me. I
would prefer for patches to be against Silver if possible.
But this is mostly "cherry picking" anyway, so at least
with most SCM tools (maybe darcs is an exception) it is
necessary to use a fair amount of manual manipulation of
patches anyway. So I don't think exactly what we base a
patch on is that important.

> 
> it raises the question of how patches should be done. 
> 
> i believe the point of the SVN repository was that multiple
> people can create multiple branches to work on different
> things. these different things would eventually be reviewed
> and, if accepted, merged into silver and then gold.
>

No. SVN /trunk was created to be Silver from which the
experimental branchs would be branched.
 
> axiom--silver--1 was created to be a pre-gold version of
> the system with "early release" of changes so they can be
> tested.

No. axiom--silver--1 was created to be a mirror of SVN /trunk
(now called SVN /silver) so that you would not have to deal
with the problems of using SVN.

> 
> axiom--main--1 is the "official system"
>

Right. Gold.
 
> so it seems to me that SVN branches should collect up
> changesets, post these as diffs to the mailing list have
> these applied to silver review, tested, and finally released
> as gold.
> 

I don't think there are very many of these and I believe that
all of them have already been posted to the mailing list.

Regards,
Bill Page.




reply via email to

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