--- C Y <[EMAIL PROTECTED]> wrote:
> --- "Page, Bill" <[EMAIL PROTECTED]> wrote:
>
> > Here is how I see the situation:
> >
> > | || |
> > | |darcs and |
> > |next big = hg mirrors |
> > |
--- "Page, Bill" <[EMAIL PROTECTED]> wrote:
> Here is how I see the situation:
>
> | || |
> | |darcs and |
> |next big = hg mirrors |
> |experiment | |
> gold | /
What I know for sure is that I have five students who all have hard
time with Axiom silver and I had to give them
axiom.build-improvements. One group is working on formal power series,
and the other is working on algorithmic differentiation.
What exactly is the goal of the formal power series g
> > 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 plat
root <[EMAIL PROTECTED]> writes:
[...]
| are you trying to say that silver patches get backported into branches?
I'm suggesting that every patch against silver be made as dealing
conceptually with one thing, so that branch maintainers can decide
whether they want to have them for the purpose of
root <[EMAIL PROTECTED]> writes:
| > 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
root <[EMAIL PROTECTED]> writes:
| > 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
| > th
> 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.
I awoke this morning to a whole series of bug status reports
changed to closed. Perhaps this is correct but I didn't see
changes to the source code patched and tested. I'm go
> 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
> pat
On 10/27/2006 10:10 PM, Gabriel Dos Reis wrote:
"Page, Bill" <[EMAIL PROTECTED]> writes:
| 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 dista
> 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 v
> Here is how I see the situation:
>
> | || |
> | |darcs and |
> |next big = hg mirrors |
> |experiment | |
> gold | /|
> gold < |
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> "Page, Bill" <[EMAIL PROTECTED]> writes:
> | Here is how I see the situation:
> |
> | | || |
> | | |darcs and |
> | |next big = hg mirrors |
> |
"Page, Bill" <[EMAIL PROTECTED]> writes:
| 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 mean
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
root <[EMAIL PROTECTED]> writes:
| > It appears that we now have at least two "trunks" under SVN --
| > ignoring for the moment, all the variations under other SCMs. That is
| > going to be more confusing to people already confused with the current
| > state of the affairs. We need to agree on T
root <[EMAIL PROTECTED]> writes:
| > 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.
|
| m
root <[EMAIL PROTECTED]> writes:
| > When build-improvements is ready to be merged into trunk, I'll propose
| > it. Build-improvements is ready when the TODO list has been moved to
| > "done" section and tested adequately. If you believe you want merge
| > piecemeal, go for it. Just beware that
> It appears that we now have at least two "trunks" under SVN --
> ignoring for the moment, all the variations under other SCMs. That is
> going to be more confusing to people already confused with the current
> state of the affairs. We need to agree on THE trunk.
well i'm in the process of merg
> 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.
merging build-improvements can happen "when it
root <[EMAIL PROTECTED]> writes:
| > Let me know what you think of this arrangement.
|
| You do realize that this leaves the build-improvement branch as
| a true fork since it is no longer "rooted" at axiom49 in the SVN tree.
|
| I think we need a person to volunteer to be the "patch-pusher"
| b
> When build-improvements is ready to be merged into trunk, I'll propose
> it. Build-improvements is ready when the TODO list has been moved to
> "done" section and tested adequately. If you believe you want merge
> piecemeal, go for it. Just beware that that is going to cause troubles
> and I d
root <[EMAIL PROTECTED]> writes:
| > Let me know what you think of this arrangement.
|
| You do realize that this leaves the build-improvement branch as
| a true fork since it is no longer "rooted" at axiom49 in the SVN tree.
|
| I think we need a person to volunteer to be the "patch-pusher"
| b
> Let me know what you think of this arrangement.
You do realize that this leaves the build-improvement branch as
a true fork since it is no longer "rooted" at axiom49 in the SVN tree.
I think we need a person to volunteer to be the "patch-pusher"
between build-improvements and silver. The job in
Your automatic procedure should show the top entry in CHANGELOG of:
20061026 tpd src/interp/setq.lisp add Christian Aistleitner
If this is NOT the top entry then something is broken.
t
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
h
> The reason I decided to leave /trunk was that in fact there
> are quite a large number of changes from /trunk to your new
> /silver and resolving these differences will take some time.
> If I just applied your version to /trunk a number of changes
> there would end up being reverted, or vice-ver
> To the best of my ability to research the subject, it seems
> that having two (or more) roots in an svn repository will not
> cause any problems.
The trunk/branch/tags are just names and have no significance
in SVN. They are there by convention.
t
__
27 matches
Mail list logo
