James is a great project but sometimes we take to longYes. And one of the things that held us up for a long time was making changes that blocked our ability to get good releases out the door. I'd like to learn from that, and avoid a repeat. --- NoelIf this is referred to anything happened in the last year I'm interested going deeply, otherwise it is old stuff and ASF is made by people and not by past scenarios.
As a help to understand this point, I'll describe what happened in the past, until last year. Noel and Danny can tell more about it.
When I started using/working with James in early 2003 there were (if I recall well) three main streams in CVS: trunk, a branch related to v3 (I don't remember its name - lets call it "old_v3") and "branch_2_1_fcs".
At the time old_v3 and branch_2_1_fcs had already diverged a lot, not in terms of functionalities but mainly in terms of architecture, (and I don't even know what was the status of trunk). Every commit had to be done twice, and many times the committed code had to be different. It was a pain on the neck.
branch_2_1_fcs was less "on the front", but was always working and widely tested, and so the various 2.2.0 alpha and RC releases came out from it, up to final 2.2.0 around June 2004.
There was also a difference between the two branches related to different avalon release.
At a certain point I stopped myself committing to the two branches, as I considered the "old_v3" somehow out of control, and it was impossible to know if all commits were applied also to it. Also the other committers started behaving this way. We were instead all sure about the "integrity" of branch_2_1_fcs. So that was the "real" trunk for all of us.
On May 2005 Noel spent a lot of time migrating everything from CVS to SVN, and creating by hand a new trunk starting from branch_2_1_fcs + an avalon upgrade + useful things from "olf_v3. I gave him some help in cleaning and testing, being very careful in doing that because the architectural differences between branch_2_1_fcs and the new trunk were delicate and prone to subtle errors. This activity was completed succesfully on June (or beginning of July) of 2005, and my production system is the trunk that came out of this process and is perfectly working (and I suppose also Noel's). It was a very painful process, that took a long time.
The fear that I have now, and I think that some other committer has, is that if we do not concentrate now on coming out with a final 2.3.0, only testing, applying fixes and adding *non* architectural/refactoring changes until we get it out, we risk to diverge again very quickly and again lose control and enter again in a long delay before a release.
I hope that this helps in clarifying the different attitudes among us and in getting things less bitter and more relaxed.
Vincenzo
Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
