minutes of ESC call ...
Bjoern Michaelsen
bjoern.michaelsen at canonical.com
Mon Aug 13 11:10:23 PDT 2012
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
More information about the LibreOffice
mailing list