First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
A list for the developers of CellML tools

Text archives Help


[cellml-dev] [cellml-discussion] Announcement of PCEnv 0.6rc1 (release candidate for PCEnv 0.6)


Chronological Thread 
  • From: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-dev] [cellml-discussion] Announcement of PCEnv 0.6rc1 (release candidate for PCEnv 0.6)
  • Date: Thu, 26 Feb 2009 16:01:15 -0000
> From: cellml-tools-developers-bounces at cellml.org [mailto:cellml-tools-
> developers-bounces at cellml.org] On Behalf Of Andrew Miller
>
> Alan Garny wrote:
> > Sorry, but in-house testing is not the same as testing by the
> community,
> > even though I appreciate that some in-house testers may also be
> 'proper'
> > end-users. Anyway...
>
> We could consider changing the period between release candidates and
> testing, but we have several things to balance up:
> * We want to maintain our fairly lightweight release process and get
> things out to users fast.
> * We don't want release candidates to become de facto releases (which
> is what will happen if we wait too long before going to release).
> * We don't want to go through too many release candidates because of
> the amount of time it takes to formally release them... hence the
> policy
> that only catastrophic problems will result in a new release candidate.
>
> Perhaps this would be easier to discuss if you suggested how long you
> thought the timeframe should be... my concerns about lengthening the
> timeframe would apply to a much lesser degree if you mean that we
> should
> lengthen the timeframe to, say, 10 days, compared to if you are
> suggesting that we stay in release candidate phase for months.

I had 2 weeks in mind per release candidate (or, ideally, 3 weeks to account
for people being away, etc. but I do appreciate that this might a bit too
long).

> A few points to note:
> * Not every user has to test the release candidate - only one or two
> do. If some are busy in that period, that is fine, because there will
> be
> more potential users to test it.

I just hope there will be some people happy to test it, full stop. As I said
previously, if someone was to do a good job, then I reckon it should take
them at least one full working day.

> * Non-catastrophic problems can be fixed in the next release - we aim
> to make a release every 6 months so it isn't that long to wait. Really
> keen users can work from snapshots and help us identify problems early
> -
> before the release candidates are prepared.

I suppose you mean that if there are workarounds to known non-catastrophic
problems? Well, I do appreciate your point of view, but from an end user's
perspective I would hate it if I had to rely on a workaround to do something
that should have worked in the first place. I mean that in our case, it's
easy to say that 6 months is not that long to wait, but for someone who has
to use a piece of software day-in day-out, those 6 months are going to be
very long and frustrating indeed.

> * Historically, we have not had any very serious problems come up
> after the release candidates were released, which suggests that the
> current timeframe is working at present. We would therefore want to
> have
> good evidence / reasons to believe that things would improve before
> changing this.

Have we ever monitored who has tested previous versions of PCEnv and what
the outcome was?

Alan



Archive powered by MHonArc 2.6.18.

Top of page