Re: [vote] gump-related stuff

2005-06-20 Thread Daniel Fagerstrom

Stefano Mazzocchi wrote:


We should try to make it easier for gump to work with us. Our build
system is a little hacky in that regard since it uses partial gump
information to build cocoon.

Gump strongly suggests people to move their gump descriptors over to the
gump repository, so that all apache committers have access to it, not
just cocoon committers. This increases the ability for others to fix the
problems that we might introduce. At the same time, this is not
possible, since our build depends on that *and* we can't svn:externalize
it because the gump metadata is not (yet!) in SVN (we could get it from
viewcvs, though, but it sounds hacky)

So, the easiest thing is to allow gump committers to modify our
'gump.xml' files.

So, issue #1: would you like to allow this?
 


+1


  - o -

There is another issue: cocoon has unique packages that we only depend
on and we place them in our gump.xml file, problem is that later on
other projects might start using those and collisions might happen. Gump
is not really happy when naming collisions happen (its datamodel is not
namespaced, yet) so one way to do it better is to ask the gump folks to
package the things we depend on directly. Means that its a little slower
turnover.

So, issue #2, would you like to ask the gump people to move our library
dependencies currently in gump.xml over in the gump metadata repository
instead?
 


+1

/Daniel



Re: [vote] gump-related stuff

2005-06-18 Thread Jörg Heinicke
> --- Ursprüngliche Nachricht ---
> Von: Stefano Mazzocchi
> Datum: Fri, 17 Jun 2005 08:37:25 -0400
> 
> So, the easiest thing is to allow gump committers to modify our
> 'gump.xml' files.
> 
> So, issue #1: would you like to allow this?

+1

> So, issue #2, would you like to ask the gump people to move our library
> dependencies currently in gump.xml over in the gump metadata repository
> instead?

+1 Why not? If we do not have to maintain them ... What should be the
downsides?

Joerg

-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl


Re: [vote] gump-related stuff

2005-06-17 Thread Sylvain Wallez

Stefano Mazzocchi wrote:


We should try to make it easier for gump to work with us. Our build
system is a little hacky in that regard since it uses partial gump
information to build cocoon.

Gump strongly suggests people to move their gump descriptors over to the
gump repository, so that all apache committers have access to it, not
just cocoon committers. This increases the ability for others to fix the
problems that we might introduce. At the same time, this is not
possible, since our build depends on that *and* we can't svn:externalize
it because the gump metadata is not (yet!) in SVN (we could get it from
viewcvs, though, but it sounds hacky)

So, the easiest thing is to allow gump committers to modify our
'gump.xml' files.

So, issue #1: would you like to allow this?
 



+1. Let's knowledged gumpers fix the descriptor when then find errors 
rather than having to send patches.



  - o -

There is another issue: cocoon has unique packages that we only depend
on and we place them in our gump.xml file, problem is that later on
other projects might start using those and collisions might happen. Gump
is not really happy when naming collisions happen (its datamodel is not
namespaced, yet) so one way to do it better is to ask the gump folks to
package the things we depend on directly. Means that its a little slower
turnover.
 



What does this mean concretely? That the libs we depend on will be 
managed at Gump?



So, issue #2, would you like to ask the gump people to move our library
dependencies currently in gump.xml over in the gump metadata repository
instead?
 



Don't know yet...

Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director



[vote] gump-related stuff

2005-06-17 Thread Stefano Mazzocchi
We should try to make it easier for gump to work with us. Our build
system is a little hacky in that regard since it uses partial gump
information to build cocoon.

Gump strongly suggests people to move their gump descriptors over to the
gump repository, so that all apache committers have access to it, not
just cocoon committers. This increases the ability for others to fix the
problems that we might introduce. At the same time, this is not
possible, since our build depends on that *and* we can't svn:externalize
it because the gump metadata is not (yet!) in SVN (we could get it from
viewcvs, though, but it sounds hacky)

So, the easiest thing is to allow gump committers to modify our
'gump.xml' files.

So, issue #1: would you like to allow this?

   - o -

There is another issue: cocoon has unique packages that we only depend
on and we place them in our gump.xml file, problem is that later on
other projects might start using those and collisions might happen. Gump
is not really happy when naming collisions happen (its datamodel is not
namespaced, yet) so one way to do it better is to ask the gump folks to
package the things we depend on directly. Means that its a little slower
turnover.

So, issue #2, would you like to ask the gump people to move our library
dependencies currently in gump.xml over in the gump metadata repository
instead?

-- 
Stefano.