- From: alan.garny at dpag.ox.ac.uk (Alan Garny)
- Subject: [cellml-dev] buildbot update: from now on, please pay attention to buildbot status changes
- Date: Thu, 23 Jul 2009 13:14:31 +0100
>
> 1) Shouldn't we, for political reasons, separate the CellML API and
>
OpenCell
>
> build systems? As it stands, it gives the impression that OpenCell and
>
the
>
> CellML API projects are tightly coupled and, most importantly, that
>
OpenCell
>
> is *the* CellML tool by excellence. Whether any of these is true or
>
not is
>
> irrelevant here, but it nonetheless remains that we shouldn't give
>
that kind
>
> of impression.
>
>
>
I think that all it indicates is that both share development resources,
>
and for the most part, people, at the Auckland Bioengineering Institute.
>
Only people involved in development of the CellML API and OpenCell are
It's not "AND", but "AND/OR" and because it could be "OR", then some people
might not want to receive OpenCell-related messages.
>
likely to use the buildbot, and they will understand the relationship
>
between OpenCell and the CellML API, so I don't think this is a huge
>
issue.
I seem to remember 'heated' discussions about some people (and that would
include myself) wanting to make a clear separation between the CellML API
and OpenCell. One of the reasons being political indeed.
>
> 3) Why do an incremental build and not a complete build? I remember
>
> (personal) cases where an incremental build would succeed, but then
>
the
>
> generated code would fail/crash, while a complete build would be fine.
>
I
>
> agree that a complete build takes longer, but it would be safer. If
>
> anything, maybe it's something that could be done in addition to
>
incremental
>
> builds and at less frequent intervals?
>
>
>
This is in fact what happens - nightly builds are complete builds, while
>
incremental builds happen as things are checked in. We do need to
>
improve our dependency system - it is a bug in the build system if
>
incremental builds don't do the right thing, although not necessarily a
>
large enough one to warrant spending much time on, as it is so easily
>
worked around.
I disagree about your last point. I have 'wasted' time in the past when
things would fail/crash. I, obviously, assumed that it had something to do
with my code, so I would double check it over and over again, and then I
would eventually realise or be told that it might have been a problem with
the incremental build (and it usually was).
Otherwise, the work around may be easy, but it's still somewhat time
consuming if you have to recompile the CellML API.
>
Releases are based on clean builds, the purpose of the incremental build
>
is to check for problems.
That is fine, but the latter must use reliable incremental builds...
>
> 4) Do such emails mention who is responsible for the failure (i.e. the
>
> person who did the last push)? I think that would save people a bit of
>
time
>
> (e.g. if I am not responsible then I could 'ignore' the email... :)).
>
>
>
It does list people who have pushed since the last build in the e-mail.
Yes, I realised that yesterday night (Auckland time).
>
> 5) I wish the builds were on the 'Y axis' and the timings on the 'X
>
axis'. I
>
> believe this would allow to see all the different builds at once (at
>
least
>
> for those of us who have a big enough screen resolution) and one would
>
just
>
> have to scroll horizontally to see their results through time. At the
>
> moment, one has to scroll both horizontally and vertically.
>
>
>
There are different views, but that is the only one with both timings
>
and builders. This one shows the latest status of all builders in one
>
screen:
>
https://autotest.bioeng.auckland.ac.nz/cellml-admin/one_box_per_builder
I don't seem to have access to it.
Alan
Archive powered by MHonArc 2.6.18.