Kelly Campbell wrote:
> > -----Original Message-----
> > From: Alex McLintock [mailto:[EMAIL PROTECTED]]
> > I'm not going to argue whether or not a rewrite is a good
> > idea but it is
> > pointless to expect business to pay for the rewrite. Business
> > is all about
> > immediate results and immediate profit. Just about every client I've
> > ever had says something like "Never mind the quality, just
> > deliver it ASAP."
> If this is true (which I don't neccessarily beleive), then this is a case
> where business gets in the way of what I think the ASF is trying to achieve.
> We want to make sure what we build is useful to businesses, but we also want
> to make sure that it has quality which is sustainable in the long term. If
> you ask me, there has been way too much short-term focus by businesses
> recently because of market conditions which I don't want to see creep into
> Apache projects. Apache and the ASF projects are mainly foundation laying
> projects, and you have to make a long term investment in this kind of
> infrastructure for it to be worthwhile. I'm speaking for myself only here,
> but I hope what I'm saying echos the Apache vision.
Hear, hear. My general view of the current state of software
development is that it is being more and more finely tuned to the
production and distribution of bugs. It is largely the pressures
mentioned above that are driving this development. Open source software
is keeping open the possibility that what was once called the art of
computer programming may survive, and with it such deceptively simple
things as good design, good workmanship and the pride of the workman in
his work. (I hope I need not point out the traditional universal
coverage of some terms used in the previous sentence.) So much for the
> > Open Source projects succeed by lots of hands doing many
> > small changes. A rewrite
> > is best done by one person or small team working dedicated on
> > the project.
> I agree. Many testers are needed to make sure the rewrite does everything
> it did before, unless we have a comprehensive regression test suite. (Arved,
> Keiron, and others have been working on this test suite)
> > If we have to wait three months (say) for the next major
> > release then FOP will die.
> > Unless FOP can be developed in an evolutionary way, rather
> > than a revolutionary
> > way it will fail.
> I also tend to agree with this. I predict it will take more than 3 months to
> make this really happen. I'm in the final stages of a similar
> refactoring/rewrite on a project comparable in size to FOP, and it has taken
> 6 months for a small team to really do it right. In that particular case we
> had lived with and added features to the initial version for over a year,
> but it became quickly apparent that the cost of maintaining the old while
> adding very minor new features was very high. After the rewrite, we've been
> able to add in major new features very quickly, and the overall quality of
> the second generation project is much higher. I would love to see the same
> happen to FOP.
> You are right that we must support the old releases in the mean time.
And again, hear, hear. Tasks have their own inherent time constraints
based on their own inherent level of difficulty - they take their own
sweet time. That said, there is an imporant variable. In the old days
there was a lot of talk about finding the right language to express the
problem and its solution. The classic example was Roman vs. Arabic
notation. Long division in Roman notation was not an exercise for the
faint-hearted. Although we have a very useful general-purpose language,
the problem and its solution are not actually expressed in the language
itself. They are expressed at some higher level or levels; call it the
model, the paradigm, the myth, the story. Getting this language wrong
is like trying to do long division in Roman notation.
Finding the, or a, right language is what Karen and Arved are currently
engaged in. I hope to be able to assist in this process.
I'm sorry to tell you what you already know, but ever since I started
programming I have been amazed at the ubiquity of the view that the
process of expressing an application in a computer language was somehow
automatic, and that any one solution was as good as any other, except,
of course, that the first was always the best.
> > After being negative for a few seconds, let me be more
> > practical and pragmatic.
> > What you are calling for is support
> > (financial/technical/time) so that people
> > can build the basis of FOP V2.00
> > I'd like to see Fop 0.19 CVS still developed whilst that is
> > going on. I think
> > you were saying that it is difficult to fund this work
> > whilst a redesign is
> > going on. Hmmm. Maybe. Maybe not. I'd say that bug fixing was
> > easier to
> > get paid for than a re-write.
> I'm in agreement here as well. I think we need to continue to push bugfixes
> and new features into FOP 0.XX. The only problem is resources. It would be
> hard for our group of committers to do both. If you look at the Cocoon
> 1/Cocoon 2 development, I think they had two teams... one to maintain and
> bugfix the old, and another dedicated to the new. I think that is what we
> have to do for a FOP rewrite. Also, I don't think we're talking about a
> complete rewrite from the ground up. We're mainly talking about the core
> processing of the fo to area tree. How closely the renderers are tied to
> that implementation will determine how much reuse we get out of them.
> > Do we have any volunteers to re-write FOP? Anyone with the
> > skill and understanding
> > to do so?
> I personally plan to help, however I cannot be a lead on this as I have too
> many other things in my job and personal life that have to take precedence.
> I think Karen and Arved have the best understanding of the overall project
> and the spec to lead this effort. I hope they have the time, and I hope I
> can find the time as well.
I think the framework for this division of labour is already in place.
Karen should be free to concentrate on the new design, except when she
feels the need to cut some code to keep her feet on the ground. Arved
knows exactly when to give direction like the statement that started
this thread, and is available for Karen to sound out ideas. There seem
to be a number of people who are contributing bug fixes, including new
contributors. I want to work on the new design, and, for the time
being, I can work on this full time. But my flywheel turns exceeding
slow from a standing start, although I am useful when I get up to
speed. Right now, I am trying to get up to speed in Java. I hope I can
get involved before it's all over.
Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]