Chronological Thread 

< Chronological >      < Thread >

---

Hi all,

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.

A release candidate is a point that should be stable enough that a
user could actually use it with a good expectation that it will behave
like a release. What we are looking for is areas that the release
candidate does not behave like a release. In the past we have delayed
the release candidate to deal with non-crasher bugs. The most obvious
of these are layout bugs, but we could conceivably block for any bug
that is either a regression, or reasonably annoying.

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.

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.

Best Regards,
Justin.



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

• [cellml-dev] [cellml-discussion] Announcement of PCEnv 0.6rc1 (release candidate for PCEnv 0.6), Justin Marsh, 02/27/2009

---

Archive powered by MHonArc 2.6.18.