Gump dates and times (Was Re: junit reports output)

[Sebastian Bazley <Se...@london.sema.slb.com>]

----- Original Message ----- 
From: "Adam R. B. Jack" <aj...@trysybase.com>
To: "Gump code and data" <gu...@jakarta.apache.org>
Sent: Wednesday, December 03, 2003 1:37 AM
Subject: Re: junit reports output (Re: cvs commit: jakarta-gump/project ws-axis.xml)


> [...] Sadly I think they just missed
> this build. Hopefully covalent will pick those up.

Which reminds me:
The build logs on covalent and cocoon show the start times of each project in the summary list, whereas the lsd list does not.
If one is waiting for a build to run, it is useful to be able to scan the times of builds earlier in the sequence. Any chance of
that being added to LSD?

It would be useful to be able to display the times in GMT (or even better, local time for the browser), to make it easier to follow
the sequence of Gump builds.

Another suggestion would be to do the CVS fetch just before the build, to reduce the time-lag between them.
If there is an error in a build, updates can easily miss the next one or two CVS runs, reducing turn-round for fixes.

S.

Re: Gump dates and times (Was Re: junit reports output)

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

> The build logs on covalent and cocoon show the start times of each project
in the summary list, whereas the lsd list does not.
> If one is waiting for a build to run, it is useful to be able to scan the
times of builds earlier in the sequence. Any chance of
> that being added to LSD?

 Good point. Added to CVS.

> It would be useful to be able to display the times in GMT (or even better,
local time for the browser), to make it easier to follow
> the sequence of Gump builds.

I've added timezone. I know these big public Gumps could work in GMT, but I
think localtime w/ timezone is best for private ones, so chose that.

> Another suggestion would be to do the CVS fetch just before the build, to
reduce the time-lag between them.
> If there is an error in a build, updates can easily miss the next one or
two CVS runs, reducing turn-round for fixes.

So do CVS/build, CVS/build not CVS/CVS, build,build ? That what you are
saying? I am open minded to the idea, but not sure how it helps what you
suggest. A run takes a finite amount of time, updates occur once a day (or,
at most) once each of those finite times. How does your suggestion help?

I've tried added the time of the CVS update to the build log.

regards

Adam