Debian Gump

[Arnaud Vandyck]

Mark Wielaard wrote:
> Hi,

Hi Mark, Hi Leo, Hi all,

> Thanks. Unfortunately I still haven't setup Gump myself.
> I have CCed Leo Simons which has been helping a lot with the kaffe setup
> and gave a presentation on Gump at Fosdem. Hopefully he has some raw
> estimates on resource numbers.

I remember the great presentation ;-)

> General setup instructions are at:
> http://gump.apache.org/gettingstarted.html

I'll read it when I'll have some time but I'll wait for an estimation
about the resources needed by gump.

> We also have to come up with a free workspace for gump. The default has
> some non-free binary dependencies.

Which ones?

> One interesting idea would be to have
> gump depend on the actual unstable/experimental Debian packages
> themselves (but building them from source of course). Gump normally uses
> current CVS sources. But for Debian it might be more important to get a
> current state of Debian testing/unstable/experimental overview using the
> Gump. Since that is what your users are going the got in the end.

I know this and I already discuss with Dalibor about that situation. To
help kaffe, GNU Classpath, and others (we definetly have to find a
simple name to call the gang!), it's better to build 'stable' software,
I mean if ant devs break the cvs, everything will break (same with
xalan, etc...) of course it does not happen often but it'd be better to
run gump with libs and applications that are in debian. That way, we
could see exactly why a software will not build etc.

The problem I see here is: how to upload a package that does not build!
I mean at the moment, we build packages with kaffe when it's possible,
not when it's not! If it's not possible to build the package with kaffe,
(or with another free runtime/compiler), we have to build it with
non-free JDK in order to upload it. Maybe we have to try to pass some
'magic' envvar to tell the package to build with kaffe and not with
non-free JDK. In that way, we'll have interesting results (but not if we
upload only packages that we already know can be build) but it's not a
trivial job and we'll have some packages to change!

One thing that could be interesting is to run the unit tests. I think
unit tests should not be blockers for our packages, but gump could log
them and give us good informations about the real state of a package.

Comments?

-- 
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html