Hi Mathias,
Mathias Bauer schrieb:
Ingrid Halama wrote:
This is not sufficient. Heavy code restructurings and cleanups are not
bound to the feature freeze date,
Perhaps they should? And at least as far as it concerns me they are.
but have a great potential to
introduce regressions also. I think the show-stopper phase must be
extended in relation to the feature-phase *and* the normal-bug-fixing-phase.
Furthermore what does it help to simply let different people do the
nominations while the criteria are not clear? So I would like to suggest
a criterion: In the last four weeks before the feature freeze only those
(but all those) CWSses get nominated that have a complete set of
required tests run successfully. Same for the last four weeks before end
of normal-bug-fixing-phase. We could start with the tests that are there
already and develop them further.
The problem is that the usual test runs obviously don't find the bugs
that now bite us, most of them have been found by users or testers
*working* with the program. Adding more CWS test runs and so shortening
the time for real-life testing will not help us but make things worse.
The problem is a bit more complex. The testers and test script writers
do not have any time for writing new test cases for new functionality,
they do not have time to check fixed issues in master, they do not have
time to check code changes in a CWS as much as they should and at the
end you are right, they do not have the time for real-life testing.
But at the last point I want to relativize a little bit. The QA
community and the L10N testers find critical problems in DEV build very
early. Most of the regressions which were reported in the past days on
the releases list, are regressions in the very past builds. Some of the
issues weren't identified very early by Sun employees, because they have
to look in a lot of issues these days to identify the show stoppers.
So the QA project has a big problem with the mass of integrations.
Because they cannot check every new functionality on regular base,
because they do not find the time to write the corresponding test cases
for VCLTestTool and they do not find the time, to check if the
functionality is correctly integrated in the master build.
I think we need to
- stop with larger code changes (not only features) much earlier before
the release. We should not plan for finishing the work right before the
feature freeze date, if something that is not critical for the release
is at risk we better move it to the next release *early* (instead of
desperately trying to keep the schedule) to free time and space for
other things that are considered as critical or very important for the
release.
+1
- make sure that all CWS, especially the bigger ones, get integrated as
fast as possible to allow for more real-life testing. This includes that
no such CWS should lie around for weeks because "there is still so much
time to test it as the feature freeze is still 2 months away". This will
require reliable arrangements between development and QA.
+1
- reduce the number of bug fixes we put into the micro releases to free
QA resources to get the CWS with larger changes worked on when
development finished the work. This self-limitation will need a lot of
discipline of everybody involved (including myself, I know ;-)).
+1
Ah, and whatever we do, we should write down why we are doing it, so
that we can present it to everybody who blames us for moving his/her
favorite feature to the next release. ;-)
+1
Regards,
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
