Niclas Hedhman wrote:
On Monday 01 November 2004 17:00, Leo Simons wrote:
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.
For the record, there are 8 attempts at starting a Gump build every day.
1 is Kaffe, 1 is JDK1.5, 1 is 'test' and the others are the official build.
So, it is not completely accurate to say that the Kaffe build instance doubles CPU/disk resources.
The kaffe build increased our disk usage of 7Gb (about 1/6 of our resources) and uses 56 CPU minutes and one 3 hours time slot (about 1/8 of our resources).
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.
Looking at the fact that a Kaffe developer (dalibor) has taken interest in Gump, installed his own instance and trying hard to get things going, is IMHO a good testament to the appreciation of Gump.
Not only that. The build on Kaffe is a political tool for the java community: it's the only way to show that "we have a way out" if Sun decided to do something weird licensing-wise with their JVM. This would be a *huge* service to the java community at large and to the ASF in the first place.
If you have a figure showing this saves significant cpu/disk space that we need for other stuff, you'll get (grudgingly) a +1.
CPU/disk is basically a financial issue. If it is constrained today, we can take temporary measures to exclude projects to make room.
We do not have disk-space issues at the moment, but we are not able to get another build in the house.
Before going financial, I would spend some time in making sure that the builds could land into another part of the disk. that would reduce disk consumption by an order of magnitude.
Some external dependee projects don't build, and is 'annoying' in the reports.
This is my main concern: their failures are basically "cry wolf", when a real failure happens, nobody notices.
We can either remove them, or choose a better snapshot from their CVS.
The result would be the same.
Those are short-term issues, and I think that removal of non-fixed dependee projects are adequate in the short-term.
What we should start discussing is, how do we scale Gump 'real big'?
Niclas, there are *tons* of things to do in gump before we even start attempting that. Please, let's fix our problems first.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
