Hi André,
most of the point are interested for QA-project. Therefore I linked it
to the dev-qa list and set the followup to [EMAIL PROTECTED]
Last Friday I talked with Jacqueline Rahemipour about the idea of a
Beta. We agreed that when more feature are integrated into updates it is
needed to improve the testing on these new feature.
We discussed the following :
- date for UI/Feature-Freeze means, all Feature must be ready until
this date; in the next Master build all features are integrated
- this Master build should listed in Release Map and should be announced
for feature testing in Dev-QA List
- test case specifications for the new Features can be provided by Sun
QA-team
- these test cases can be adopted and expanded by testers from QA
project; these test case specifications should be a skeleton
- how the testing can be organized and where and how these test cases
can be stored should be discussed
With this action, we should be able to find regressions, feature or
changes, which are not so welcome in OOo earlier. And perhaps we do
not need so much RC's anymore.
What do you think about the point above?
Thorsten
Andre Schnabel wrote:
Hi,
Cor Nouws schrieb:
It is not that your resistence is coming from the fact that some
aspects of QA are still under construction?
Yes. And QA will always be under construction, the same way as our
release process is.
Some thoughts about the process are in a mail from february:
http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgNo=5872
Unfortunately, the progress to make this ideas happen is very slow. But
we are working on it. Thorsten Ziehm had some suggestions (I still need
to answer). I hope, I meet Joost next weekend to discuss some ideas.
...
So reading in another mail from you (current thread)
You know the difference between a Release Candidate and a beta
version and the meaning of it?
It looks as if you say: minor releases ought not to go without a
beta-phase.
And maybe it is not even clear if the current release/QA-resources can
keep up with the current release-shedule.
With all respect for Chad Smith's deepest knowledge about our
QA-Process, What we currently do is not RC - testing.
A release Candidate is supposed to have no critical errors and should be
ready for release within a very short test cycle. Ideally, this would
mean, your first RC is ready to release. Usually you would have two or
three RC's. We had 7 for 2.0.3, 5 for 2.0.2. 2.0.1 had just one RC, so
this one was ok. But we had heavy discussions before 2.0.1 and spent
more ressources than usually to find regressions and mayor bugs.
All of our releases have been delayed because they did not meet the
quality . 2.0.2 was quite ok .. only a week behind. 2.0.1 and 2.0.3
about a month!
The idea to go from development to RC to release would work, if the risk
of regressions is low, if the amount of changes is low and if the
feature set is not (or only slightly) changed. This (almost) worked in
1.1 codeline.
But now we have more features. They come in with every release. Of
course they are tested. They are tested in CWS, the are tested in our
snapshots .. but by all we do for testing those features, we are not
perfect. The common approach is to have a public beta, once the features
are integrated. So we would get more feedback about those features.
At the moment it is even hard to identify, what build is feature
complete. Ok, we have the dates for last CWS integration for features,
but there is no visible information, if this has been met.
One last thing .. why I asked, what kind of features we will see in
2.0.x (or now 2.x) series is exactly the problem of Beta vs. RC testing.
Wiht only small features coming in, we could stay with RC testing and
(maybe) even reduce the amount of work. With more features coming in, we
need another approach and we could think about it.
But without the question being answered, we cannot say, what we should
do. .. We only could do (what ever this might be).
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
