gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: How to detect "Friends of Gump"
Date Tue, 08 Apr 2003 20:54:36 GMT
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.

This is not the first time in the history of Gump that Fop has had a 
major redesign.  Like Avalon was for the first year or so of Gump, Fop 
seems to be a project in perpetual alpha.  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.

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.

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.

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.

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.

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?

- Sam Ruby

View raw message