Chronological Thread 

< Chronological >      < Thread >

---

Hi,

> As KDE 4 has recently demonstrated, merely asking for user input and
> testing at various (non-release) stages often does not help. While
> generally we go into feature freeze just before we start the first
> cycle of release tests, in practice the majority of features that may
> make it into each release are decided on at the release planning
> sessions that happen at the start of the cycle. Also, asking people to
> test potentially randomly broken snapshots mid release cycle does not
> usually seem to go over well for some reason... We could flag
> snapshots which are stableish (which is what I informally do, when I
> ask James to use a particular snapshot), in order to get testing mid
> cycle. I would like it if this could happen, but most people without
> specific needs (for example, DAEs) do not seem to be interested in
> becoming bleeding edge users, which makes sense.

It's always a risk and, to be honest, I think it's the same with the release
candidate. I mean that some people might just prefer to wait for the release
itself, hoping that other people will have 'checked' the RC for them.

Still, based on what Andrew suggested and what Justin is saying here, I
think it might be a good idea to flag stableish snapshots and let the
community know about those, so that those who are interested and have time,
can test them.

At the end of the day, anything that could provide more than just one week
of testing of a RC ought to be a good thing. This doesn't mean that we would
necessarily get more feedback, but at least there is potential for it. On
top of that, if the solution doesn't involve more work (as would be the case
here), then it would be 'silly' indeed not to do it.

> To have a reasonable expectation of finding any of these which would
> crop up in daily use we don't need a large group of people to
> systematically test the software (though that would be nice), but for
> a reasonable number of people to use it reasonably, along with a small
> group of people who use snapshots regularly. Strangely, what I am most
> concerned about with this release candidate is that there will be
> something basic in the Mac OS version that I have overlooked, which
> was not exposed when Catherine tested it, such as some common
> resolution exposing a flaw in the layout of the model tree view,
> rendering it entirely unusable.

This is the primary reason for which I started raising this whole issue of
the RC and timeframe for feedback. I am sure you guys have done your very
best to test the Mac OS version, but we never know indeed!

> What I would propose is that we try to get releases down to one every
> three months (we are currently at roughly one every four over the
> period I have been part of the project), with some snapshots in the
> middle, or near the beginning if they fix something that we did not
> block on for the release, flagged as stable to stableish, depending on
> how they hold up to a reduced or informal test set.

+1

Alan

---

• [cellml-dev] [cellml-discussion] Announcement of PCEnv 0.6rc1 (release candidate for PCEnv 0.6), Alan Garny, 03/02/2009

---

Archive powered by MHonArc 2.6.18.