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. 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. ;-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
