gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Date Wed, 09 Apr 2003 13:20:03 GMT

On 08.04.2003 22:54:36 Sam Ruby wrote:
> Jeremias Maerki wrote:
> > Uh, I think we should try to create a second Gump run for the
> > maintenance branch of FOP. The Cocoon FOP block is based on the
> > maintenance branch and should be for the next few months. But FOP's Gump
> > run is loaded from HEAD and represents the FOP currently in redesign.
> > And that API has changed and will change again.
> > 
> > The tag to use would be: fop-0_20_2-maintain in the xml-fop module
> > 
> > Is that an easy thing to do?
> > 
> > On 08.04.2003 19:25:05 Sam Ruby wrote:
> > 
> >>Question: is cocoon-block-fop a friend of gump?
> > 
> > Jeremias Maerki
> 
> Is is possible?  Yes.
> 
> Will I resist it?  Yes.
> 
> What is 2 to the 100th power?  A very big number.
> 
> Permit me to explain.

Good thing you do. :-)

> This is not the first time in the history of Gump that Fop has had a 
> major redesign.

When did Gump start? I'm following the FOP project since Fall 2000 and
I am a committer for 12 months now and there's only one redesign effort
I'm aware of. More below.

> Like Avalon was for the first year or so of Gump, Fop 
> seems to be a project in perpetual alpha.

Not true. Only because our releases have version numbers like 0.20.4,
0.20.5 doesn't mean we're in perpetual alpha. The general agreement is
that version 1.0 should be the version that supports at least basic
conformance level of the XSL-FO spec. Maybe that decision was bad with
hindsight. Fact is that a lot of people use FOP in production and most
are very happy even if we still haven't reache basic confirmance level.

> Avalon I now have some real 
> hope for.  I'm not so sure of Fop.  I know that seems unduly harsh, but 
> I sense that that's the real essence of the metric that Stefano is 
> seeking: projects that one dare not depend on because they are currently 
> (and possibly perpetually?) in redesign.

Being in redesign and having an unstable API are two different things.

Redesign started in fall 2001 and continues today. The reason was to be
able to reach basic conformance level in the first place because it was
found that it wasn't possible with the existing codebase. Releases come
from the maintenance branch mentioned in the other mail. We're finally
reaching consensus not to release another version from that branch after
version 0.20.5 which is due soon. The two-track way cost us a lot of
power especially in this light: It happens that the whole team with the
exception of about two people gradually left the project being replaced
by others. But I'm pretty sure that wasn't because (!) the redesign got
started even if you may get the impression. Loss of know-how and power
while our pretty huge user base remained and had to be made happy.

Well, maybe the FOP team should have requested a separate CVS space for
the redesign as other projects did. Maybe that had brought us some
different feedback in this matter. Maybe we shouldn't have called our
production releases 0.20.x.

> The reason I asked the question above is that the initial metrics that 
> Stefano proposed would lead one to the conclusion that fop is like junit 
> - one never sees a failure.  And that cocoon-block-fop is like xindice - 
> fails continuously but nobody cares.

Double-nag Cocoon and FOP! Helps the Cocoon guys and prevents us FOP
guys from accidentally changing the API (which I admit happened before).

> Now, to answer your question: it IS possible to build individual 
> versions of each dependency.  So we can build 2 versions of fop.  Now 
> consider the sheer combinatorics of building the individual versions of 
> each dependency that each project has declared that they depend on. 
> That's a very big number.

In this light you should probably delete quite a bunch of Gump projects.
Fact is that FOP still has two main development tracks as do other
projects so it may make sense to have the two even if it is just for our
feedback.

> Now lets look at the information value of doing such a build.  Presumaby 
> the people within Cocoon frequently build with the snapshot version of 
> fop that they have checked into their cvs.  That path is therefore well 
> tested.  Reproducing that build with the maintenance version of fop 
> provides marginal additional information.

No. It would give the Cocoon guys greater confidence if they want to
upgrade their version of FOP and that's not marginal IMO. Also makes
sure that it's easier for a Cocoon user to upgrade the FOP version
locally without asking for trouble.

> Depending on my mood, my recommendation is to either to remove the nag 
> but keep the build for cocoon-block-fop.  Or to change the destination 
> of the nag to be fop's dev mailing list, i.e., the true culprits.

As I said: double-nag. That's what encourages communication. Blaming
anyone doesn't help.

> Now, let me turn the question around: is is possible for fop to create a 
> deprecated compatibility api to ease the transition for projects like 
> cocoon who have been valued 'customers' of fop since pretty much the 
> beginning of the project?

Should be doable although I'm pretty unhappy to reintroduce some ugly
things from the past (MessageHandler). I'll ping the team. We're trying
(with the redesign) to get away from the bloody static constructs used
all around FOP. Just look at the Cocoon-FOP-block sources to see how the
Cocoon guys dislike FOP's API. And they are right.

My take:
- Add a Gump run for FOP's maintenance branch
- Let cocoon-block-fop depend on the maintenance branch for the moment
- Double-nag FOP and Cocoon lists for cocoon-block-fop
- FOP team will look into improving the API situation


Jeremias Maerki

Mime
View raw message