gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: [proposal] removing non-ASF leaves from the workspace
Date Mon, 01 Nov 2004 09:00:57 GMT
Stefano Mazzocchi wrote:
> there are a few projects that gump builds that are not ASF projects and 
> are not used by any ASF project.

I'm not sure which projects this is about (or what the projects you 
listed are about), but I can imagine that these projects are built 
against the "latest and greatest ASF software" to make sure that ASF 
software doesn't introduce incompatible changes. ie Cocoon might like 
Gump to build Daisy as its a good integration test for cocoon.

Abstractly, projects depend on having good dependees available inside 
the system as a measure for their own backwards compatibility.

> I think the ASF already has enough 
> things to build for ourselves and gump is not a public service.

The ASF is a public service in a way though :-D. I like how gump as a 
project and a community has tried so hard to reach out to all parts of 
the oss world, not just the ASF.

Abstractly, requiring dependees to be ASF-internal leads to a closed 
ASF. No good.

> I personally think that it is abusive for comitters to use their access 
> to add projects that are not required.

whoah. Around here stuff like that used to be okay, encouraged even. 
Gump is now pushing in a somewhat different direction (which I support) 
so we're changing some of our ideas on this, but that doesn't make the 
people not quite aware of those unspoken 10-mile-high goals abusive all 
of a sudden.

> Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm 
> sure I can found more (and, in fact, I'll write some code to outline 
> those and automate the checks).
> I propose that we remove those projects from the gump.xml profile that 
> is ran on brutus (we can keep the descriptors there, that doesn't hurt) 
> but I would like to remove all those "leaves" projects from using 
> cpu/disk space.

Kaffe is very much a leaf not a dependency (I know no ASF project that 
can only be built using Kaffe), yet using it for experimental runs 
doubles the amount of cpu and disk space used.

While I appreciate the goal of being able to have a truly free java 
stack and how using Kaffe to build ASF projects helps towards attaining 
that goal, we're also doing "public service" towards the GNU people in 
this way.


If you have a figure showing this saves significant cpu/disk space that 
we need for other stuff, you'll get (grudgingly) a +1.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message