On Mon, Aug 13, 2012 at 10:26:57AM -0700, bfo wrote: > Or maybe change in the base code workflow is needed? > 1. design the change
currently done > 2. find out which modules are affected would require a lot of cleanup in the codebase to make sensible predictions for nontrivial changes here. We are working towards that, but we inherited a _lot_ of cruft. > 3. plan testing If you change e.g. refactor SfxItemSet that might impact ~everything. From a prediction point of view our tests are good enough. Realistically though there are cornercases, that wont get cought by unittests or subsequenttest. And we wont catch those cornercases if we spend a year on writing tests. They are cornercases and our codebase is huge. > 4. code > 5. prepare unit tests Shouldnt 5 come first? > 6. careful code review (not just OKeying) Will you help there? > 7. commit in the unstable branch currently done. > 8. QA confirm currently done implicitly for every bug not reported by QA at branchoff (because there is to few testing of master). > 9. commit in the stable branch currently done > I think many bugs introduced are an effect of omitting one (or more) steps > from that list by the developer. nope, I think you are just underestimating the size of the codebase (and the range of our target platforms). Suggested reading: Michael Feathers, Working Effectively with Legacy Code > Maybe gerrit will help to achieve this in some way... It will, with automated testing and, if the QA community grows a bit (well a lot), also with manual testing. Best, Bjoern _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
