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.
   -- 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.

   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.
(Aside: I disagree with the "only model that seems to work" bit. Not everyone has a short attention span.)

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.

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.
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.

"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to