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: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] [cellml-discussion] Announcement of PCEnv 0.6rc1 (release candidate for PCEnv 0.6)
  • Date: Fri, 27 Feb 2009 10:19:16 +1300
Alan Garny wrote:
>> Andrew wrote:
>> 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).
>
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.

>> * 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?
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.

> 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.
>
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.

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.

>
>> * 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?
>
I'm sure we would hear about it from someone if a release didn't work at
all on any significant number of systems.

Best wishes,
Andrew



Archive powered by MHonArc 2.6.18.

Top of page