[Libreoffice] dev300 merge thoughts / some lessons ...

On Fri, 2011-03-18 at 16:44 +0100, Thorsten Behrens wrote:
> Merging from OpenOffice.org's DEV300 code line

        Soo ... I guess I wanted to say a few thoughts on this, and what was
learned in the process.

        Firstly - apologies; there are almost certainly bugs introduced as a
result of the merge: both human errors, and machine merging ones - these
are hard to avoid, and after six straight hours of reading and deciding
on patch fragments, it is possible to get quite tired.

        Ergo - if you're chasing a bug; it can be useful to look at the code
versions on both ooo/DEV300_m101 and also the
LO-BASE-INTEGRATION-DEV300_M101 tag.

        Similarly, if you have done your best to remove all the random 'OD'
style comments from writer - there are now some more :-) Similarly, I
imagine most dead-code cleanup tasks, and cppcheck runs and so on will
sprout yet more interesting fruit; so please be patient. It is a also
possible that one or two fixes have been missed: please test your pet
features.

        Apart from that - I think we learned a few things:

        * whitespace changes just for the sake of it, are a
          PITA to resolve
        * re-sorting enumerations, or esthetic line re-ordering is
          also not ideal :-)

        Of course, some work is inevitable - we translated a ton of German
comments, on lines that then had type changes, leading to a lot of this:

A:      BOOL bSaveState;  // whether we should save the state
B:      sal_Bool bSaveState; // Ich bin ein berliner

        Or somesuch ;-) in future we may need to do more automation of such
changes, and/or merge smaller chunks.

        There are a few known regressions; help on these much appreciated (cf.
Thorsten's mail), eg. fixing the About dialog.

        Another problem is that the gnumake build system tends to copy
libraries around instead of hard-linking; which rather increases the
build tree size: my build is 18Gb small [ though I have a few extra
pieces lying around ], that is slightly up from the previous 17.5Gb or
so. Fixing solenv/gmake/Deliver.mk to use cp -l and fallback to cp -a if
that is not possible may improve things there.

        Otherwise - we got a number of really nice wins here.

        In particular Stephan Bergman's work binning the slow, bulky and
unusable services registration code - in favour of an XML services.rdb
(same name sadly) should help kick-start our cross-compiling to Windows
- which should help to further accelerate our build process.

        Of course, introducing the gnumake build system, gives us a lot of work
that can be turned into easy hacks, turning each of our modules into
gnumake enabled ones: eventually yielding a single 'make' command that
can incrementally re-compile only the files necessary, and quickly too
(as well as compiling 1000 wide or somesuch) :-) Some great work from
Bjoern / Mathias Bauer there.

        There are a lot of other things too, but - these were the pieces that
bit me off the bat doing some of the work here.

        Thanks !

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot