axiom-developer
[Top][All Lists]
Advanced

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

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


From: root
Subject: Re: [Axiom-developer] RE: gcl-2.6.8pre on MAC OSX 10.2
Date: Sat, 4 Nov 2006 12:44:31 -0500

> On a regular bases, we branch off SILVER 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 SILVER will be created for
> that purpose. That branch will have stricter rules for checking than
> for SILVER.  For example, we would not fiddle with/upgrade GCL
> versions there.  Only bug fixes will be applied to release branches
> (GOLD).  After the initial major release from that branch (GOLD), 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, SILVER develops its life.  Any bug fixes to release
> branches (that also happen to be present on SILVER) must first be
> tested on SILVER before being applied to a release branch (GOLD).
> SILVER 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 SILVER.
> 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) (GOLD).



> People will create experimental branches from SILVER.  There are
> well-defined rules about how an experimental branch gets merged to
> SILVER.  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."  SILVER should be open to move more aggressively in its
> "experimental" phase.  Release branches (GOLD), must be conservative.


> Notice that in my model, no changes get merged to a release branch
> if it is not a regression bug fix (GOLD).  Any new functionality
> should appear in the next major release SILVER.  Everything is
> publically available in a lively fashion.  The most stable branch
> (to serve a release source) and the main SILVER.
> 
> To my mind, we can have many repo if that is felt necessary, but: only
> one repo is the master (GOLD), 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.





I made a minor name-edit to your text to reflect my understanding
of the current situation. s/trunk/silver/ and s/release/gold/

It seems your model differs from the current model in only one
truly essential aspect. You feel that I'm a bottleneck and that
Axiom cannot develop properly if a single person is in charge
of the final version. You feel that this limits what people can do
and that I'm holding back Axiom development. You feel that such a
centralized "point of failure" cannot work.

Linux is developed with this same centralized model.
Linus controls all of the things that get accepted, essentially GOLD.
Andrew Morton controls his version of the kernel, essentially SILVER.
Linus and Andrew are both "points of failure". Indeed Linus is 
regularly flamed on the kernel mailing list for his decisions
(e.g. to use BitKeeper, to write GIT, to reject ReiserFS, etc).
It is stated regularly that he's holding back Linux, that he's
a control freak, that he's arbitrary and misguided and that the
central model of development cannot work. Axiom uses the same
model and you're making the same arguments.





Gaby, at this point we've raised every question and answer.
What remains unsettled is my role in the development process.

I'd like to hear from the other people lurking on this list.
What is your opinion. Try to speak freely and clearly.
My feelings will not be hurt so don't mince words.

Tim





reply via email to

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