Keiron has responded to specifics, so I will make a couple of general points below...
Victor Mote wrote:
...
I realize that I am jumping into this conversation in the middle. I am ignorant of the history of how we got where we are, so **please** understand that I am not being critical. My first exposure to an open-source project was when I started monitoring this list on July, and I have no idea how other projects operate. However, I have done some reading on the subject, and my reading generally agrees with my own intuition. I think we are in danger of violating a cardinal principle of open source development, and indeed of software development in general
Indeed indeed. There's nothing particular to OSS development here.
However,-- that you operate as much as possible with code that works.
1) its can't always be done, and
2) doing it can be digging yourself an even deeper hole.
One of the greatest OSS projects of them all. Mozilla, had a large and successful code base to work from, but started from scratch.
(Aside: I disagree with the "only model that seems to work" bit. Not everyone has a short attention span.)Unless you have massive amounts of resources (and probably there as well), the only model of software development that seems to work is an immediate feedback loop. The sequence is 1) recognize a need, 2) implement (plan and code), 3) test, 4) answer the question, "Is the code better with this than it was before?" 5) iff "yes", check it in.
The main line development is not working from existing code and functionality; it's trying to get new functionality which is frustrated by the existing design and code. That's not the whole story. A lot of things can be and have been improved within the existing framework. A lot of this discussion is about the difference between the two, and whether that difference requires different handling.
An important point to make about FOP is that a conscious decision was made some time ago that the redesign would stick with the existing framework and not be a ground-up reworking. The methodological changes now being discussed are only possible because of that decision, strongly argued by Keiron, I believe.Now, I understand that sometimes you come to a chasm like the redesign. (I am not yet smart enough to understand the issues, but I will take the gurus' collective word for it). It is not practical to complete the entire work in one step, yet you still need a place to record the incremental changes as you move along. In other words, first you break it in some radical way, then begin to fix that break around the new design -- again, with immediate feedback. I think this is what branches were designed for. You can break-and-fix as much as you want in the branch without hurting the code in the trunk.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
