News Letter

[Adam Jack <aj...@trysybase.com>]

All,

Much as Gump is daily satisfying it's primary objective of continuous
integration & keeping project sharing from going stale, I see it as needing
to be kept "current" itself. Many folks depend upon gump (as a service) with
little interest to the mechanics/maintenance/use of the software that
provides that service. I see that as unhealthy, and just plain un-Gump-like.
;-) I can see Gump getting stale if that continues. As such, I think we need
to get more people more interested in gump, and hence I've contributed this
to the newsletters.

This (below) is what I've updated in
http://nagoya.apache.org/wiki/apachewiki.cgi?GumpNewsLetterDraft. Since mine
is but one perspective, and I am a poor writer, please let me know if you'd
like to see changes. Heck, it is Wiki, just go change it.

The deadline is in two days, please review and comment.

regards

Adam
----------------------------------------------------------------------------
---------------------------------------------

(AdamJack RefactorOk) I don't know how long this should be, but to flesh
this out some...

Gump has accumulated 168 modules, providing 380 projects, and continuous
integration builds are running nightly on at least five public servers. Of
these modules, 20 have delegated their descriptors to project CVS
repositories, which allows local management of this. Gump extracts source
code from over 24 CVS repositories, with most CVS repositories hosting
multiple modules. Recent additions were new modules for jUDDI
(http://cvs.apache.org/builds/gump/latest/juddi.html) and Jakarta POI
version 3 (http://cvs.apache.org/builds/gump/latest/jakarta-poi-3.html).

In order to improve the process around Gump, it has been added to Bugzilla.
Users can submit bug reports and/or requests for change in an organized
process.

Gump has suffered some outages, primarily due to: hardware failures
(lightening damage), CVS locks on remote CVS servers (hanging CVS updates),
and CVS outages in remote servers. Also, with the length of a gump run now
exceeds 7 hours, which can leads to build starting generation on one day and
ending on another (exposing a @@DATE@@ problem).

Although "SUCCESS" builds are the norm, there are numerous "PREREQ FAILURE"
when builds are marked as "FAILED". This represents healthy project
sharing/re-use/cooperation, which is exactly what Gump to promotes and
facilitates. The nightly gump output (see:
http://cvs.apache.org/builds/gump/latest) reads like a dashboard on the
state of "Open Source Sharing".

Gump is starting to see more use as "private" Gumps, where the
modules/projects that are not all available for public CVS access can
benefit from continuous integration, Additionally, some installations are
for a "trimmed stack" for build speed/focus.

As a corollary, gump is seeing more use with "packages" (pre-installed base
software) -- reducing build time, and focusing the builds on specific
software. Nick Chalko contributed the ability for gump to convert module
definitions to "nobuild" equivalents, on the fly. These descriptors contain
the <jar information (for CLASSPATH dependencies) but no <ant/<cvs/<script
directives. As such, they convey the jar metadata without invoking a build.
This allows for package-based builds of the original metadata, removing
manual editing.

Further, a *nix gump.sh script is evolving to allow a standard build process
(combining the various gump build steps) to make it easier for users to
install/run their own gumps.

Work in this area is ongoing.

--
<http://www.try.sybase.com>
Experience Sybase Technology ...

Re: News Letter

[Nick Chalko <ni...@chalko.com>]

Excelent