Re: [Alert!] Major break in Excalibur!

["Adam R. B. Jack" <aj...@trysybase.com>]

> We have a big problem with Excalibur in combination with LogKit, and it
has
> been completely hidden by Maven!!!!

FWIIW: Gump has been trying to raise awareness of it. It shows this error in
the compile output.

http://lsd.student.utwente.nl/gump/avalon-excalibur/gump_work/build_avalon-excalibur_excalibur-logger.html#Output

BTW: Because this project has been in a bad state for a number of runs, Gump
has turned on ant -debug [in case the problem to not be one of source code,
but a build failure] which makes it overly verbose. If/when we get to
compiling again, the build will revert to non-debug.

Hopefully Gump can get to a point of not being the boy who cried wolf to
Avalon, so that it can give earlier warnings to folks.

regards,

Adam


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

Re: GUMP Early Warning System requires timely fixes

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

On Sat, 13 Mar 2004, Noel J. Bergman <no...@devtech.com> wrote:

> What ideas has the GUMP team come up?

Search a bit back for a [RT] thread initiated by Stefano.

We really want to do more than just report that something is broken.
We will need to keep information about "last good builds" so that we
can go back to them and start to replace dependencies from the good
set with last nights versions to identify the culprit.

> Is the plan the aforementioned use of an earlier build combined with
> notification to all downstream users about the build failure?

We haven't gone that far yet.  This should probably happen if the
situation doesn't get fixed fast enough.

Right now the focus has more been on how to identify the dependency
that is responsible for a build failure and less on how to help the
projects that cannot build because of pre-req failures.

We certainly need to address both and backtracking to a known good
state will help with both.

Stefan

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

GUMP Early Warning System requires timely fixes

["Noel J. Bergman" <no...@devtech.com>]

> FWIIW: Gump has been trying to raise awareness of [the compile
> problem in Excalibur]. It shows this error in the compile output.

Adam,

The problem for a project like James is when something is broken early in
the dependency chain, nothing after that gets the benefits.  So by the time
we get notification of a problem, it could be, and has been, 6 months or
more of API, and other, changes in code that we're dependent upon.

Not sure what the answer is, since if GUMP just switches to building against
previously successful builds, we don't get the warnings related to the code
that is changing and broken.  On the other hand, if the chain is
A->B->C->D->E-F-G, we can see that if B is broken, and F is changing, it
might be helpful to go ahead and use B' on the hope that C will still build
with it, and G can see that it is getting F'ed.  If C still doesn't build,
try D against C', etc.  It is intended for GUMP to run on a dedicated
server, so compute cycles should be available.

What ideas has the GUMP team come up?  Is the plan the aforementioned use of
an earlier build combined with notification to all downstream users about
the build failure?  At the least, if dependencies don't build for a
sufficient period of time, you should start periodically notifying
downstream users.

Any other ideas?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

GUMP Early Warning System requires timely fixes

["Noel J. Bergman" <no...@devtech.com>]

> FWIIW: Gump has been trying to raise awareness of [the compile
> problem in Excalibur]. It shows this error in the compile output.

Adam,

The problem for a project like James is when something is broken early in
the dependency chain, nothing after that gets the benefits.  So by the time
we get notification of a problem, it could be, and has been, 6 months or
more of API, and other, changes in code that we're dependent upon.

Not sure what the answer is, since if GUMP just switches to building against
previously successful builds, we don't get the warnings related to the code
that is changing and broken.  On the other hand, if the chain is
A->B->C->D->E-F-G, we can see that if B is broken, and F is changing, it
might be helpful to go ahead and use B' on the hope that C will still build
with it, and G can see that it is getting F'ed.  If C still doesn't build,
try D against C', etc.  It is intended for GUMP to run on a dedicated
server, so compute cycles should be available.

What ideas has the GUMP team come up?  Is the plan the aforementioned use of
an earlier build combined with notification to all downstream users about
the build failure?  At the least, if dependencies don't build for a
sufficient period of time, you should start periodically notifying
downstream users.

Any other ideas?

	--- Noel


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