Mathias Bauer wrote:
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 is not obvious to me. Too often the mandatory tests haven't been
run. And if tests do not find an important problem, hey then the tests
should be improved.
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.
I don't agree. Preventing the integration of bugs earlier in the
production phase especially before the integration into the master trunk
would give us much more freedom. Now we always need to react on show
stoppers and react and react and uh then the release time line is on
risk. All that, because the bugs are already in the product. If you
instead detect the bugs before they are integrated into the product you
can keep cool, refuse the bad CWS and thus not the release is on risk
but only the single bad CWS.
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.
- 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.
- 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 ;-)).
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. ;-)
I am missing a stimulation for good behaviour in this plans. There are
people who do the feature design, who do the developing work, who do the
testing, who create the automatic test, who do the documetnation and
after all these people have done their work and lets assume they have
done it good and without show stoppers, after all this there comes
someone else and says, oh no, I do not think that I want to have this
for this release, there are other things that I want to have more and in
the sum I guess that it might be to much for the next release? Where is
the stimulation for good behaviour here? There is none, instead it is a
stimulation to push in the changes quickly into the product and skip
careful testing.
Come on, we will loose the good and careful people if there is no
stimulation for good behaviour.
Ingrid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
