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.



More information about the LibreOffice mailing list