Ralf Hemmecke <[EMAIL PROTECTED]> writes: | On 11/03/2006 10:22 PM, Gabriel Dos Reis wrote: | > Ralf Hemmecke <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
