Gump PMC Report 12/2006

[Stefan Bodewig <bo...@apache.org>]

Infrastructure:

    * We had a little outage after the colo migration since vmgump
      didn't come up properly.  Yet another reason to look forward to
      the beefer machine Justin hinted at last time.

Technical:

    * Stefano has set up a Gump build running on top of Harmony[1]
      which currently is stuck by not finding a javac command line
      compatible compiler.

    * Much of the gump side of Maven2 support is done, Bill Barker now
      also wants to give the Maven side a try - we need to make Maven
      use the jars created by gump instead of those from any local or
      remote repository.  There is hope.

    * sourceforge has found a new way to keep us moving stuff around.
      They are now moving the subversion repositories to virtual hosts
      per project, which means changing descriptors and deleting
      working copies on all Gump instances again.  Won't be the last
      time.

Other:

    * Sander Temme has been added to the PMC on 2006-12-01.

    * still all Apache committers have access to metadata in svn.

    * no releases.

Footnotes: 
[1]  http://67.86.14.213:10000/gump/


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Gump PMC Report 12/2006

[Geir Magnusson Jr <ge...@apache.org>]

Stefano Mazzocchi wrote:
> Stefan Bodewig wrote:
> 
>>     * Stefano has set up a Gump build running on top of Harmony[1]
>>       which currently is stuck by not finding a javac command line
>>       compatible compiler.
> 
> It should be noted that the reason why Gump can't find javac is not
> because it's not properly installed in the path (that would be an easy
> fix), but because no javac existed for harmony.

Man... first you want a classlib, then a VM, then javac... what's next, 
Solaris port?

Oh, wait...

> 
> Instead of routing around the problem, I let it hanging there to apply a
> little pressure on the harmony dev team, which in fact resulted in the
> creation of a javac executable that is now being tested. We should
> expect rather speedy forward motion on that quickly.
> 
> Note how that machine is at Geir's house. We would really like to move
> it somewhere else but vmgump is already overloaded and the gump solaris
> zone (or a new harmony zone) doesn't help because Harmony doesn't
> support solaris yet.

It will. :)

geir

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Gump PMC Report 12/2006

[Stefano Mazzocchi <st...@apache.org>]

Stefan Bodewig wrote:

>     * Stefano has set up a Gump build running on top of Harmony[1]
>       which currently is stuck by not finding a javac command line
>       compatible compiler.

It should be noted that the reason why Gump can't find javac is not
because it's not properly installed in the path (that would be an easy
fix), but because no javac existed for harmony.

Instead of routing around the problem, I let it hanging there to apply a
little pressure on the harmony dev team, which in fact resulted in the
creation of a javac executable that is now being tested. We should
expect rather speedy forward motion on that quickly.

Note how that machine is at Geir's house. We would really like to move
it somewhere else but vmgump is already overloaded and the gump solaris
zone (or a new harmony zone) doesn't help because Harmony doesn't
support solaris yet.

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Gump PMC Report 12/2006

[Steve Loughran <st...@apache.org>]

Stefan Bodewig wrote:

>     * sourceforge has found a new way to keep us moving stuff around.
>       They are now moving the subversion repositories to virtual hosts
>       per project, which means changing descriptors and deleting
>       working copies on all Gump instances again.  Won't be the last
>       time.

SVN switch appears to let you do this with relative ease. That is, 
unless you d/l svn 1.4 onto your windows box and find it silently 
upgrades all your local cache in a way that breaks all other SVN clients.

Given that moving repos is not an entirely unknown event, maybe gump 
somehow needs to automate the handling of it. Something like remembering 
the last location a repository came from, and if the location changes 
delete everything and check it out again.

-steve


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org