Re: [Axiom-developer] RE: gcl-2.6.8pre on MAC OSX 10.2

[Gabriel Dos Reis]

Ralf Hemmecke <address@hidden> writes:

| On 11/03/2006 10:22 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke <address@hidden> writes:
| > | > I'm very happy to see Tim is making changes more visible now,
| > than waiting
| > | > for ages before seeing light. The main reason I originally volunteered 
to
| > | > maintain Silver is that I do believe in "live sources". Tim suggested
| > | > at the time that he did not have time do maintain too many branches.
| > | > It therefore was a natural thing for me to volunteer to take on the
| > | > job.  Now, if Tim has more time to do the job, I'm all for it.
| > | | > However, I see practical issue here:    (1) first, we should
| > not
| > | > have one single person as authority to
| > | >       commit changes.
| > | | We are speaking here _only_ of the changes that go to the next
| > Gold
| > | release.
| > we are talking of Silver, right?
| 
| Right. Gold=axiom--main--1 only gets patches every two months.
| The gold-to-be=axiom--silver--1 is the branch that Tim commits to in
| order to prepare the next gold.

That is the current situation as it has been set recently.  
I'm not sure that was the situation in April 2006 when we set up the
framework.  At the time, I believe there was something called silver
(and its implications), which is not what is currently called silver.  


| In my understanding we requested that in order to let axiom-developers
| see how the current gold gradually develops into the next gold. We all
| agreed that Tim commits to gold. Since now that thing is called
| axiom--silver--1 does not change that.

Yes, we all agreed that Tim commits to gold; yes.  
If gold is now called silver, what is gold?

[...]

| Gaby, could you post how you think Axiom development should work? (You
| should probably avoid the usage of Gold/silver/bronze.) Just post your
| dream. Where should be the main source? How many stages should be
| there before something is released? How is quality ensured? What
| _roles_ (not persons) should be responsible for what.


Ideally, I would like to see a *main common source tree* (call it
Trunk) from which everything develops.

On a regular bases, we branch off Trunk to make release branches.  For
example, we could decide that next Tuesday, we will branch off for
Axiom 4.1.0.  A release branch from Trunk will be created for that
purpose. That branch will have stricter rules for checking than for
Trunk.  For example, we would not fiddle with/upgrade GCL versions
there.  Only bug fixes will be applied to release branches.  After the
initial major release from that branch, we will be making minor
releases from there, say Axiom 4.1.3 that are only regression bug
fixes. (Ideally, we should not have regressions, but that happens only
in dream, especially with with impenetrable systems).

In parallel, Trunk develops its life.  Any bug fixes to release
branches (that also happen to be present on Trunk) must first be
tested on Trunk before being applied to a release branch.
Trunk is less restricted than release branches in the sense that it
contains "experimental" phases where more features are added [say we
have drag-n-drop, integration of ACL, SPAD understands dependent
types, or we get rid of ')abbrev' command to introduce types, or that
SPAD understands "extend" for extending domains, etc.]  This is
usually the time where development branches are merged to trunk.
Then, there should be a period where we make "pause" in the feature
accretion, stabilize for release purposes, then branch off for the
next major release (say 4.2.0).

People will create experimental branches from Trunk.  There are
well-defined rules about how an experimental branch gets merged to
Trunk.  No experimental branch gets merged to an existing release
branch. 

During the process, we should try to do everything possible to
increase the number of people that understands the system.  This
includes, better documentation.  Even those who understand the system
should justify their changes.  People should apply their patches
directly, instead of going through a single person.  The sources
should be immediately available. 
We should use less superstition, e.g. "don't touch because it
currently works."  Trunk should be open to move more aggressively in its
"experimental" phase.  Release branches, must be conservative.

Notice that in my model, no changes get merged to a release branch if
it is not a regression bug fix.  Any new functionality should appear
in the next major release.  Everything is publically available in a
lively fashion.  The most stable branch (to serve a release source)
and the main Trunk. 

To my mind, we can have many repo if that is felt necessary, but: only
one repo is the master, others are mirrors to simplify our lives.

Now, I understand that is not what we have; I'm trying to see how it
can be approximated and made to work.

-- Gaby