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: Thu, 26 Feb 2009 13:23:20 +1300
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...
>
Hi Alan,

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.

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

Best wishes,
Andrew

> Alan
>
>
>> -----Original Message-----
>> From: cellml-tools-developers-bounces at cellml.org [mailto:cellml-tools-
>> developers-bounces at cellml.org] On Behalf Of Randall Britten
>> Sent: 25 February 2009 23:23
>> To: 'A list for the developers of CellML tools'
>> Subject: Re: [cellml-dev] [cellml-discussion] Announcement of PCEnv
>> 0.6rc1 (release candidate for PCEnv 0.6)
>>
>> As I understand it, the MacOS version has already undergone fairly
>> extensive
>> testing, which would mean that the 1 week is sufficient.
>>
>>
>>> -----Original Message-----
>>> From: cellml-tools-developers-bounces at cellml.org [mailto:cellml-
>>>
>> tools-
>>
>>> developers-bounces at cellml.org] On Behalf Of Alan Garny
>>> Sent: Thursday, 26 February 2009 11:37 a.m.
>>> To: 'A list for the developers of CellML tools'
>>> Subject: Re: [cellml-dev] [cellml-discussion] Announcement of PCEnv
>>> 0.6rc1 (release candidate for PCEnv 0.6)
>>>
>>>
>>>>>> The first release candidate for PCEnv version 0.6 has been
>>>>>>
>>> released.
>>>
>>>>>> This is the first version of PCEnv since 0.1 that can run on OS
>>>>>>
>> X;
>>
>>>>>> there
>>>>>> are also a number of other improvements since PCEnv 0.5.
>>>>>> More information, and the released files themselves, are
>>>>>>
>> available
>>
>>>> at
>>>>
>>>>>> http://www.cellml.org/downloads/pcenv/releases/0.6rc1
>>>>>>
>>>>>> A release candidate will become a release one week from
>>>>>>
>>> announcement
>>>
>>>> on
>>>>
>>>>>> this list if there are no problems identified with it.
>>>>>>
>>>>> Don't you think that ONE week (?!) might be a bit short? I mean
>>>>>
>>> that
>>>
>>>> one of
>>>>
>>>>> the biggest changes in PCEnv is that it now works under OS X. So,
>>>>>
>> I
>>
>>>> would
>>>>
>>>>> expect people wanting to test it under that operating system to
>>>>>
>>> need
>>>
>>>> a bit
>>>>
>>>>> more than one week. Even for those who use Windows and/or Linux
>>>>>
>> in
>>
>>>> fact...
>>>>
>>>> The one week period between the release of the release candidates
>>>>
>> and
>>
>>>> the final release is a long-standing policy which has existed since
>>>>
>>> the
>>>
>>>> PCEnv project was first created (and was carried over from the
>>>> mozCellML release policy).
>>>>
>>> Is that supposed to make it right?
>>>
>>>
>>>> The purpose of the release candidate period is to give
>>>> people a chance to find any particularly critical bugs in the
>>>>
>>> packaged
>>>
>>>> up version (for example, that it doesn't install / run at all for
>>>>
>>> some
>>>
>>>> reason... although we perform our own functional tests before
>>>>
>> making
>>
>>> a
>>>
>>>> release as well). It isn't intended to be a feedback period about
>>>> features or anything else like that - such feedback has to be made
>>>> before we start to stabilise for a release, or otherwise be
>>>>
>>> considered
>>>
>>>> for the next release (and so doesn't have to be in the one week
>>>>
>>> period).
>>>
>>> I don't think I mentioned feedback at any point. I think I am pretty
>>> clear
>>> what the release candidate is for. It nonetheless remains that
>>>
>> someone
>>
>>> should spend at least one full working day on a release candidate
>>>
>> such
>>
>>> as
>>> for PCEnv to find out whether it's working as expected. That would,
>>> however,
>>> be for people who have already used PCEnv before and know their way
>>> around.
>>> Now, if you think that you may have new users (incl. ones who use Mac
>>> OS X),
>>> I think it's pretty obvious that they will need to invest more than
>>>
>> one
>>
>>> day
>>> on PCEnv. You cannot, however, expect them to stop everything just so
>>> that
>>> they can check that PCEnv works fine for them. Some people may have
>>> deadlines they have to meet, may be travelling, may be on holiday,
>>>
>> etc.
>>
>>> If
>>> anything, I would allow for 2 weeks.
>>>
>>>
>>>> We always have the next release to fix bugs and support feature
>>>> requests
>>>> that come up, it is only the really critical problems that would
>>>>
>>> block
>>>
>>>> the transition from release candidate to release (otherwise we
>>>>
>> would
>>
>>>> never make a release), and so a week should be more than enough
>>>>
>> time
>>
>>>> for
>>>> that.
>>>>
>>> Yes, that's what we discussed long ago and something that I overall
>>> agree
>>> with (I would, indeed, also fix small bugs if possible).
>>>
>>> Alan
>>>
>>> _______________________________________________
>>> cellml-tools-developers mailing list
>>> cellml-tools-developers at cellml.org
>>> http://www.cellml.org/mailman/listinfo/cellml-tools-developers
>>>
>> _______________________________________________
>> cellml-tools-developers mailing list
>> cellml-tools-developers at cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-tools-developers
>>
>
> _______________________________________________
> cellml-tools-developers mailing list
> cellml-tools-developers at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-tools-developers
>



Archive powered by MHonArc 2.6.18.

Top of page