Re: Where to go with Gump?
On 2013-05-21, Adam R. B. Jack wrote: > I hesitate to reply since I've not contributed in quite some time (and > yes, that is some *significant* British understatement. ;-) But your input is still appreciated, don't worry. > 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. Yes, likely. A short-sighted "mvn does dependency management for us, we don't have this problem" mindset seems to be prevalent by now. > 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.) Good idea. In case we's near consensus that the current set of Gump gardeners doesn't want to continue with the current state of affairs, we definitively should reach out to those communities who still have metadata inside of Gump. 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 (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.j...@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.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. > > >
Re: Where to go with Gump?
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
Re: Where to go with Gump?
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?
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?
Hi Stephan If gump does go fubar then we would need to find an alternate means to supply build.sysclasspath to quote Ant folk "In Ant's caseGump set's Ant's build.sysclasspath to only and manages the system classpath" the fact that it builds APR (which is a dependency of Apache HTTPD) seems to justify its existence this little snippet from the gump website gives me the willies It is written in Python *which means we would need more than a passing familiarity with makefiles, gcc and ld * 2 years ago i worked at a site which did alot of python programming and the 'object' file was compiled as pyc (python component) i remember python version checking was non-existent and if you had the wrong version of pyc on your path it would take you days before you would be able to find the correct version source find the gcc compiler that would compile it link it to correct pyc format and then stick it on your path Am i the only advocate to converting gump to java? 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. > From: bode...@apache.org > To: general@gump.apache.org > Subject: Where to go with Gump? > Date: Sun, 19 May 2013 17:22:43 +0200 > > Hi, > > since about christmas last year we had reliability problems with the mvn > repo proxy. Those problems seem to have gone by now. I've been told > Maven Central is using a CDN and some of the nodes had some problems for > a while, so this may explain why it started to work again. Anyway. > > In January I turned off nagging and nobody ever asked why the nag mails > stopped. I saw Sebb mention it on Commons' dev list but not because > anybody had asked for it. Even the Ant folks (including myself) who > used to watch Gump closely didn't recognize the build had been failing > for a week or two. > > So before I re-enable nagging, I wonder whether there really still is > any interest in the service Gump provides. And assuming some of the > projecs are still interested whether we should prune those projects that > aren't. > > I don't really know for sure but over the past years the major feedback > I have received when I tried to engage with projects who's builds were > failing was "please turn off the nagging" - so maybe this colors my > perceiption. > > Any opinions? > > Cheers > > 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?
On May 19, 2013, at 8:22 AM, Stefan Bodewig wrote: > In January I turned off nagging and nobody ever asked why the nag mails > stopped. I saw Sebb mention it on Commons' dev list but not because > anybody had asked for it. Even the Ant folks (including myself) who > used to watch Gump closely didn't recognize the build had been failing > for a week or two. > > So before I re-enable nagging, I wonder whether there really still is > any interest in the service Gump provides. And assuming some of the > projects are still interested whether we should prune those projects that > aren't. > > I don't really know for sure but over the past years the major feedback > I have received when I tried to engage with projects who's builds were > failing was "please turn off the nagging" - so maybe this colors my > perception. 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. To answer this question for myself: no, I have no personal or professional use for Gump. In fact, the Mac OS X Gump run has been broken since I upgraded the os on the box, and no one seems to have noticed. I have had no time to investigate what is broken or how to fix it. I think Gump's premise (to doggedly compile the current HEAD against each other of as many projects as we can muster) should be valid, and a failure should be an important canary in the various development communities' respective coal mines. But if it's neither used nor appreciated, why are we still doing it? Other than "because it's there," which has mostly been my level of involvement. S. -- san...@temme.net http://www.temme.net/sander/ PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
