A list for the developers of CellML tools

Text archives Help


[cellml-dev] buildbot update: from now on, please pay attention to buildbot status changes


Chronological Thread 
  • 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.

Top of page