Jeremias Maerki wrote:
On 18.06.2006 13:26:00 Manuel Mall wrote:
<snip/>
Calling a release 1.0 is IMO quite a significant step which shouldn't
been taken lightly. What we are saying in doing so is: Here is
something we believe is ready for production use.
Yes, but neither should we put off a 1.0 for much longer. Having a 0.x
version number is a big disadvantange. OTOH, when I released Barcode4J
1.0 it was almost too perfect. Almost no serious problems and also
almost no third-party patches. No community building. One-man show. :-(
I don't think you can compare Barcode4J to FOP. FOP is a much bigger and
more complex system.
In 2005 we saw an increase in interest to help with the development of
FOP. This year I get the impression that this wave is ebbing away again.
I wonder why. But I also wonder how we can improve that. A 1.0 release
would be a good signal. Does a 1.0 have to be perfect? M$ usually needs
at least two service packs to reach a usable level for their software.
Poor excuse, I know, but still, it somehow applies. And frankly, the
quality level we can automatically maintain with our test suite today is
quite remarkable. That said, I believe FOP is ready for production use
now.
I agree with your observations. A lot of people I have spoke to are very
negative on FOP because of the way it is marked as beta and with a
version number < 1.0. I have been trying to persuade more people to use
it, but whilst it still has a beta tag I am facing an up hill battle.
FOP will only get more people willing to contribute to its development
when it gets more users and it will only get more users once we do a 1.0
release and send out the message that FOP is ready for production use.
It will certainly help if the beta tag is removed for the next release.
So from my perspective we need to answer two questions in the positive:
A) Does this version of FOP deliver a sufficient degree of compliance to
the XSL-FO spec to be considered ready for production use?
For which user? The degree of compliance the various user groups need is
quite different. For the business documents I've worked with so far in
my FO experience I wouldn't hesitate to use FOP Trunk in production.
Were I someone who needs to create book-style documents I'd probably
say: Hey, why should I use this crap if it doesn't even handle
page-number-citations correctly in a table of contents? What I want to
say is that you can't make a software usable to the same level for
everyone. There are users out there who still think XSL-FO is the right
tech to create large tabular reports with hundreds of pages. I wonder
why some managers still think they need these reports. (sorry, getting
carried away)
I agree with your observations here too.
Judging FOP Trunk by the level of compliance of 0.20.5 is certainly one
way of answering this question but it is not necessarily the only way.
B) Does it deliver those features with the required level of quality
expected from an ASF product?
We've had over half a year of bugfixing and stabilization and we have a
very precious test suite which helps keeping the number of regressions
very low. Only the renderers are not really covered by automated tests
because that's quite difficult to do right with a good ROI. That, combined
with the feedback from the community, tells me we're good enough. IMHO,
of course.
How can we answer those questions?
For A) IMO it is easy. The old FOP version (0.20.5) is used in many
production environments. If we meet or exceed compliance compared to
0.20.5 I would give A) a tick. However, ATM we are still behind 0.20.5
in some areas although well ahead in many others.
Please can you say where you think 0.92beta is behind 0.20.5? The only
issue that I'm aware of is the change of IPD mid-page-sequence.
Ok, so we need a Wiki page where we can track the progress for the view
on FOP Trunk. And we need to agree on how far we want to go before 1.0.
Yes such a Wiki would be very useful :)
Judging the quality of the FOP trunk code base is much harder. For
example, we still get reports of NPEs and AIOOBs. We don't know how it
will perform when asked to render 1000's of documents a day. We don't
know if there are any memory leaks. We don't know if its thread
safe....
Yes the fo:block inside fo:wrapper is a big one ATM. Although 0.20.5 has
no beta mark and it has far more NPEs and AIOOBs.
<snip/>
Yes, it's a balancing act. But we've been too shy with our version
numbers in the past. I don't like to see that continue for too long.
We've lost a lot of supporters along the way. I want to get over that
damn 1.0 barrier. Soon. And we have to do that with our limited
resources.
I completely agree.
Chris
