gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: Where to go with Gump?
Date Tue, 21 May 2013 10:14:40 GMT
Stefan (and crew)


I am Glad to hear gump creates maven pom.properties..that relieves the maven developer from
endlessly typing maven -Dparam1=value1

 

Gump goal of Generating Metadata:

if the defining goal of gump is generating metadata .. maven now supports the following function
metadata declarations

1)distributed repositories
2)configurable order of execution
3)version declaration for all artifacts

4)quick generation of customised plugins by implementing 'AbstractMojo'


Gumps replacement of XSLT and Bash with Python:
replacing xslt and bash with python probably drove more developers away from maintaining as
you moved from 
OpenSource readable scripts

to
proprietary binaries 


If *any* proprietary binaries go fubar then you're back to hunting for 
version specific C file
version specific header files
version specific gcc compiler
version specific linker
and PRAY your include,lib,path environment variables are configured correctly for your host
and architecture


Continuous Integration Tool(s)
Most Continous Integration tools I have seen e.g, Thoughtworks CI tool CruiseControl suffer
from lack of configurability

In fact i would add Unattended Continous Integration tools provide value *only when*
1)they are configurable
2)the tool source is OpenSource instead of using proprietary binaries


not picking on python perse..any "easy to use scripting tool" which compiles to binaries suffers
from the same maintainability scenarios
so where to drive gump seems to be up to the committers

Thoughts?
Martin 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité


Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.

  


> Subject: Re: Where to go with Gump?
> From: adam.jack@gmail.com
> Date: Mon, 20 May 2013 16:08:43 -0600
> To: general@gump.apache.org
> 
> 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.jack@gmail.com
> http://neukadye.com
> 
> 
> 
> On May 20, 2013, at 4:27 AM, Stefan Bodewig <bodewig@apache.org> 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-unsubscribe@gump.apache.org
> > For additional commands, e-mail: general-help@gump.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message