Standing back (for a while?)...

[Niclas Hedhman <ni...@hedhman.org>]

Gang,

I have decided to step away from Gump for a while, and the main reason is that 
I find it depressing to work with...  Increments of overall success is slow, 
and decrements of overall success is fast. And during the period of big 
showstoppers, entropy sets in in all non-building projects so that when the 
big showstopper is resolved, a lot of small cases are back.

I find that there must be something fundamentally wrong with Gump, if it 
self-deteriorate so quickly. Personally I think the solution is that the Gump 
group needs to work more intimately with the Ant/Maven and other build system 
groups, to put in the continous integration support directly into those 
tools, instead of the manual labour of bolting it on externally.

I might be back later, but for now I wish you all Good Luck.

Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.dpml.net       /
 / http://niclas.hedhman.org / 
+------//-------------------+


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

Re: Standing back (for a while?)...

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

On Mon, 29 Nov 2004, Niclas Hedhman <ni...@hedhman.org> wrote:

> I have decided to step away from Gump for a while,

Many thanks for the huge load of work you've done so far, without you
we would have never come to > 90%.  Hope you'll come back some time.

> and the main reason is that I find it depressing to work with...

I understand you, I really do.  It is quite simple to destroy the
success of months with a single commit and this certainly burns out
people.

> I find that there must be something fundamentally wrong with Gump,
> if it self-deteriorate so quickly.

But this seems to be looking at Gump the wrong way.

It's not Gump that deteriorates, its the network of projects that Gump
builds.  The network simply doesn't build, no matter whether Gump is
there or not.  If it doesn't build, it's a problem of the network (in
particular of the projects that fail), not Gump's.  Gump's purpose is
to identify problems, so in a sense Gump is more successful if the
build fails than if everything (seems to) build(s) well.

> Personally I think the solution is that the Gump group needs to work
> more intimately with the Ant/Maven and other build system groups, to
> put in the continous integration support directly into those tools,
> instead of the manual labour of bolting it on externally.

One of the benefits of Gump is, that it doesn't require any
collaboration from the projects Gump builds.  We need to collaborate
if something doesn't build because of cross-project problems, but we
don't need any help to try building something.  If the developers of a
project had to actively do something for continuos integration to
happen, it could only work on a much smaller scale.

> I might be back later,

I hope so.

Cheers

        Stefan

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

Re: Standing back (for a while?)...

[Leo Simons <ls...@jicarilla.org>]

Niclas Hedhman wrote:
> I have decided to step away from Gump for a while, and the main reason is that 
> I find it depressing to work with...  Increments of overall success is slow, 
> and decrements of overall success is fast. And during the period of big 
> showstoppers, entropy sets in in all non-building projects so that when the 
> big showstopper is resolved, a lot of small cases are back.

dude, I know how you feel!

> I find that there must be something fundamentally wrong with Gump, if it 
> self-deteriorate so quickly.

hmm. I think that the basic outline you've given above is correct. It 
simply is much easier to destroy a build (give me any java project out 
there and I can stop it from building with a single-character change in 
one file. Probably can do it blind-folded, too.) than to fix one.

That said, we can change *a lot* about those negative feelings. Work in 
progress. Suggestions (complaints, even!) welcome.

> Personally I think the solution is that the Gump 
> group needs to work more intimately with the Ant/Maven and other build system 
> groups, to put in the continous integration support directly into those 
> tools, instead of the manual labour of bolting it on externally.

hmm. In the case of ant, it'll just have to be "bolted on" since it 
doesn't have a "metadata descriptor" model. You might call the stuff you 
"bolt on" magic or maven or whatever. The same will probably remain true 
for tools that build using configure && make && make test.

> I might be back later, but for now I wish you all Good Luck.

thanks for all your hard work. Let's hope gump evolves into something 
that makes you want to come back and continue your efforts ;)

cheers,

- Leo

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

RE: Standing back (for a while?)...

[Eric Pugh <ep...@opensourceconnections.com>]

Niclas (and Gang),

I can understand how you feel, and I think that part of the issue is that
building from the latest and greatest all the way up and down the tree is
somewhat of an impossible task.  I know for example that until
commons-configuration does another release, fulcrum-configuration won't
build due to API changes.  Right now, everybody is failing because Velocity
hasn't kept up with Log4j.  And, on a certain level, expecting a component
to keep up with CVS head of another component isn't realisitic.

The things that I think would help are:
1) Identifiable people for each component.  If there ISN'T an Apache owner
for a component, it should be a library.   We need someone who will get the
fix in ASAP when the build fails.  Jakarta-velocity has been broken for 33
runs, leading to either 150 or 165 projects to not attempt to build.  Who
will fix it?

2) Need the fallback!  With jakarta-velocity failing, Gump apparently tries
but fails to fallback to the previously built version.  The fallback is
crucial to prevent the small errors from creeping in.

3) Don't email me when a dependency starts building and therefore I build.
I don't care if I build successfully because a dependency built.  I only
care when I fail.  When something with a lot of dependencies builds, I get
spammed a million times by Gump, which leads to the "Gump being ignored"
syndrome.

My 2 cents, and I hope after a breather you rejoin!  You've personally done
a lot to help me learn Gump, and get the fulcrum components to build
happily.

Eric



> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Monday, November 29, 2004 8:36 AM
> To: general@gump.apache.org
> Subject: Standing back (for a while?)...
>
>
>
> Gang,
>
> I have decided to step away from Gump for a while, and the main
> reason is that
> I find it depressing to work with...  Increments of overall
> success is slow,
> and decrements of overall success is fast. And during the period of big
> showstoppers, entropy sets in in all non-building projects so
> that when the
> big showstopper is resolved, a lot of small cases are back.
>
> I find that there must be something fundamentally wrong with Gump, if it
> self-deteriorate so quickly. Personally I think the solution is
> that the Gump
> group needs to work more intimately with the Ant/Maven and other
> build system
> groups, to put in the continous integration support directly into those
> tools, instead of the manual labour of bolting it on externally.
>
> I might be back later, but for now I wish you all Good Luck.
>
> Cheers
> Niclas
> --
>    +------//-------------------+
>   / http://www.dpml.net       /
>  / http://niclas.hedhman.org /
> +------//-------------------+
>
>
> ---------------------------------------------------------------------
> 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