Re: Where to go with Gump?

[Stefan Bodewig]

Hi Martin,

I'm not sure I fully understand what you are trying to say.

On 2013-05-20, Martin Gainty wrote:

> Am i the only advocate to converting gump to java?

Gump used to be written in a mix of Java, XSLT and bash.  It has been
reimplemented in Python - partly in the hope to attract more developers.

The code base driving Gump hasn't seen significant changes in years, the
biggest modifications have been made to support the maven proxy by
dynamically creating a Maven settings file (the proxy itself is written
in Java and never been touched by more than one person, BTW) and support
for additional SCMs.

Maybe the code base is complete and does what it supposed to do well
enough?

My question is more whether there is any sense in continuing patching
the meta data that configure Gump, something that only requires
understanding Gump's concepts and no coding at all.  This and
maintaining the infrastructure required to run Gump.

I don't believe we'd find enough volunteer power to re-write Gump even
to the point of functionality it provides now - no matter which platform
we'd chose for it.

[off-topic sidenote, if I were to implement a system like Gump again I'd
build in support for distributed executions from the start and likely
choose a platform that makes coordination of distributed processes
easier.]

Stefan

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

Re: Where to go with Gump?

[Stefan Bodewig]

On 2013-05-19, Sander Temme wrote:

> Yes, this makes it seem that we are performing a thankless task.
> Perhaps the right question to ask is who here at the Gump PMC is using
> its facilities to good effect, since we constitute the minimum viable
> community to keep it going.

It's not easy for me to admit that, but currently I mainly look after
Gump "because it's there".  At one point in time I took every
non-trivial build failure as a reason to contact the involved parties
but have been worn out by now.

Stefan

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

Re: Where to go with Gump?

[Adam R. B. Jack]

Stefan et al,

I hesitate to reply since I've not contributed in quite some time (and yes, 
that is some *significant* British understatement. ;-)

As somebody who found them self sucked away from Gump, I want to express my 
appreciation (and admiration) for all the Gump efforts over the years. There 
may be no direct uses of Gump but every issue resolved early is a valuable 
contribution to the full stack of projects hove there, with countless hours 
saved from fighting incompatibilities, and OSS productivity gains.

That said, the fact that the burden of metadata maintenance has been on Gump 
committers speaks volumes (either to it's usability or it's acceptance.) 
Perhaps the value that Gump provides (i.e. early warning of backwards 
compatibility issues) is just too far removed from those working on projects to 
be anything more than a nagging annoyance. It is a voice for the user of a 
library, but few seemed to appreciate it as such. Maybe if it only built stacks 
of pre-release candidates to ensure that releases were compatible (or at least 
discontinuities were accounted for) it would get more respect. Not sure.

I definitely believe that Gump committers alone should NOT do the bulk of the 
metadata maintenance and issue resolving, however I wonder if it is the type of 
services that won't be missed until it is gone, and if this discussion should 
be put to a wider community (once fully discussed here.) 

regards,

Adam

Adam R. B. Jack
adam.j...@gmail.com
http://neukadye.com



On May 20, 2013, at 4:27 AM, Stefan Bodewig  wrote:

> On 2013-05-19, Sander Temme wrote:
> 
>> Yes, this makes it seem that we are performing a thankless task.
>> Perhaps the right question to ask is who here at the Gump PMC is using
>> its facilities to good effect, since we constitute the minimum viable
>> community to keep it going.
> 
> It's not easy for me to admit that, but currently I mainly look after
> Gump "because it's there".  At one point in time I took every
> non-trivial build failure as a reason to contact the involved parties
> but have been worn out by now.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
> 


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