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 22:10:21 -0000
> Alan Garny wrote:
> >> Andrew wrote:
> If we stayed with the policy of catastrophic problems only blocking the
> release, it would just add one week on to the release process, because
> it is unlikely that any catastrophic problems (e.g. it doesn't start,
> you can't load models, or it has a security problem) that existed would
> have been missed in the first week.
>
> If we were to allow smaller problems to be fixed after a release
> candidate, we could potentially be in RC for months, because there will
> always be problems for people to find - often these 'problems' are a
> case of users not liking the design. The period has to restart every
> time we find a problem, so it is not just one 2 week cycle, it could be
> dozens of two week cycles. For example:
>
> We spend a day on testing
> We make RC1
> 12 days go by
> Someone finds a minor bug.
> We take 2 days to fix the bug, and one day on testing
> We make RC2
> 13 days go by
> Someone finds a minor bug
> We take a day to fix the bug, and one day on testing
> We make RC3
>
> and so on... there could be no end to this cycle, and all the while we
> are spending a lot of time making releases and fixing things in the old
> version. It could easily be that 6 months later we haven't made the
> current release, let alone that we are ready to make the next release!
>
> As such, it is in the user's interest that we get releases out fast and
> get working on the next release sooner, rather than spending a long
> time
> trying to achieve the futile task of making a particular release
> perfect
> for every user.

You are extrapolating on what I said and this is certainly not the way I was
seeing things.

Of course that minor bugs should be left for the next release or we might
end up in the situation you described, though we could limit ourselves to
one RC with report for medium+ bugs allowed (I know, it's a bit vague, but
that could maybe be decided among the development team and project leaders
as what bug should be considered a medium+ bug), then another RC (if
necessary) where only critical bugs are allowed.

What I am trying to say here is that the tests performed in-house may not
include things that some end-users might perform on a daily basis, simply
because the testers are not 'proper' end-users.

> If users happy to work with bleeding edge software are testing the
> trunk
> regularly, they can find bugs while we are still working on the trunk,
> and so we can fix bugs and accept feedback on user interfaces at that
> stage. Lots of users actually work from snapshots... knowing that the
> code hasn't been tested and might not work, and that is the price they
> pay for getting bleeding edge code.

To be honest, I would think of anyone using bleeding edge code for their
research to be completely foolish.

> They can always go back to the previous version of the software if they
> prefer it, or use a snapshot if they want to risk using untested
> software.

To go to a previous version of a software is not always possible. The new
version might include features (e.g. Mac OS X support) that is essential to
them...

> It is better that users wait 6 months than having them wait years for
> us
> to get a release out because we won't release until people stop finding
> problems with it.

You are once again extrapolating on what I said.

Also, people can't always afford to wait 6 months. This is, in fact, the
reason the release cycle of COR has always been 'dictated' by the needs of
my end-users. Now, I appreciate that my way of doing things is somewhat
unorthodox, which is why I would probably not recommend it for PCEnv (that
would indeed involve too much work), not to mention that it may not be
applicable to PCEnv.

> > Have we ever monitored who has tested previous versions of PCEnv and
> what
> > the outcome was?
> >
> I'm sure we would hear about it from someone if a release didn't work
> at
> all on any significant number of systems.

In other words, we haven't.

Alan



Archive powered by MHonArc 2.6.18.

Top of page