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 11:32:03 +1300
Alan Garny wrote:
>> 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.
>
How about this approach, which doesn't delay the release so much:
We make the following announcements at the appropriate points in the
development process to the community:
* We are coming up to feature freeze in 2 months... please review
snapshots (we don't specify which one, but say where to get snapshots
generally) and suggest any new features you think should be implemented
before then.
* We are planning a release in 2 weeks... please review snapshots and
identify any bugs you think would affect your daily work.
* Release candidate made - please check (specify exact build) to
ensure it runs on your system. Any less serious bugs should be reported
so they can be fixed in the next release.
* Release made - please report any bugs you find so they can be fixed
in the next release.

This avoids the extra process delays (and means a release candidate is
really a release candidate, not an alpha or a de facto release) which
would distract us from improving PCEnv, but it prompts users to give us
input at the appropriate points in the process.

> 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.
>
The aim of the full functional tests in Litmus is that we aim to have a
test for every feature in the user interface of PCEnv... backend
features like support for particular types of models are supposed to
instead be tested in the unit tests (although these could obviously be
improved too).

Best regards,
Andrew



Archive powered by MHonArc 2.6.18.

Top of page