axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] sourceforge/silver


From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] sourceforge/silver
Date: 27 Oct 2006 19:21:03 +0200

root <address@hidden> 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"
| between build-improvements and silver. The job involves 
| 
| 1) lifting out and purifying a difference between silver and BI.
| 2) checking the documentation
| 3) applying the change to a copy of silver (bronze == silver + one change)
| 4) testing bronze
| 5) sending a "diff -Naur silver bronze" to the mailing list
| 6) making sure it gets applied.
| 7) rinse and repeat

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.

Now, you realize why I've been so pesky about you sending patches to
the list when you apply then to your branch.  I appreciate you have
had issues with the tools.  I don't know what happened, but I'm glad
to see you're now concerned about refrain from large divergences.

For this to work properly, we have to agree on several things.

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.  We also need to
agree about patch protocol.  From my perspective, much of what we
agreed on back in April 2006 still hold.  I would like to add one more
thing:  That patches to silver be "self-contained" in the sense each
patch deal with conceptually one thing -- except of course for merges
from branches to trunk where we have already set the policy I think.
The reason for that is that it makes it easy for people to select the
patches they want to see on their branches.

-- Gaby




reply via email to

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