[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Regression Dashboard
On Saturday 24 May 2008 16:21:48 Frank Sweetser wrote:
> Kern Sibbald wrote:
> > Hello Frank,
> > Thanks again to Dan Langille for suggesting and pushing for this project
> > as well as running nightly FreeBSD regressions, and to you for getting
> > the scripts running, the dashboard setup, hosting the dashboard site,
> > and running nightly regressions.
> > This definitely a very significant help to the project in being able to
> > see the test results on a variety of machines, and to be able to drill
> > down to any errors that do show up. I don't know how I ever lived
> > without it.
> > We are now able to automatically test a number of Linux distros, FreeBSD,
> > and Solaris on a nightly basis, which will surely improve the quality of
> > the Bacula code.
> I'm very glad to be able to do this. Anything that helps make Bacula a
> better project is fine by me =)
> > Anyway, aside from the above thanks, is there any way that you can get
> > the dashboard to show date/time in CET format? Since most of the
> > developers are running on CET, it would be very helpful -- especially for
> > the "experimental" test runs that we do before committing.
> Well... mostly.
> I've told the dashboard server process that it's in CET timezone, so any
> future submissions will get shown from that perspective.
> However, it seems that the timestamps in the database are stored without
> any associated timezone information! I'm not sure whether this limitation
> is in the dart application itself or the derby database backend it uses,
> but it means that all of the existing timestamps will be shown exactly as
> they were, rather than shifting to reflect the change in timezone. Quite a
> silly limitation in this day and age, but there it is.
Well, that is no problem at all for me. Typically after a couple of days, I
don't look back at old data, and if I do, I can very well make the mental
adjustment during the transition period.
I am not sure how much historical data you keep or how much you want to keep,
but off hand, I would say that anything more than 2 or 3 weeks doesn't make
much sense. Generally, anything that breaks we look at and try to fix as
soon as practical so it is more or less a forward moving process ...
> Luckily, the timezone information is at least present in the ctest data
> files, so going forward all newly submitted results should reflect the CET
> timezone properly.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.