On 02/12/10 17:18, Christian Lippka wrote:
If you change code at one place, you may cause an assertion to
trigger at another place.
Since triggered assertions indicate programming errors, the above
sentence is equivalent to If you change code at one place, you may
introduce a programming
On 02/15/10 10:16, Stephan Bergmann wrote:
On 02/12/10 17:18, Christian Lippka wrote:
If you change code at one place, you may cause an assertion to
trigger at another place.
Since triggered assertions indicate programming errors, the above
sentence is equivalent to If you change code at one
Hi Stephan,
Not necessarily. The point is that triggered assertions need to be
sufficiently rare.
Okay, perhaps we can agree to strive for this goal first, and postpone
the rest of the discussion. Perhaps we can try aborting discussions, and
see how they work, perhaps we have other ideas
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Bjoern,
Assertions should be tested with the common tests (cwscheckapi has
decent code coverage) preventing the non-pro master to become unusable.
Ah!
Did you know that testtool, the program for running automated UI level
tests on
ANNOUNCEMENT: OOO320 release code line goes Mercurial
=
With the OOo 3.2 release safely out of the door we'll switch the OOO320
release code line (or rather now: maintenance code line) to Mercurial.
The next milestone on this code line will
Hi Mathias,
On Monday, 2010-02-15 12:34:10 +0100, Mathias Bauer wrote:
startup would become ~6% larger by converting all #ifdef DBG_UTIL to
if (bDBG_UTIL==true). The influence on startup performance would be a
little bit less than this 6%, but probably measurable.
[...]
bDBG_UTIL would be
Hi Mathias,
I tend to like the idea of using non-pro builds in QA, but we must
recall why we have stopped to do that in the past. Rüdiger mentioned the
performance problem, maybe there have been others.
Would be interesting to know. The only thing I heard in the past
whenever I asked is, hmm,
Hi!
I have a problem. Yesterday I tried to build Open Office from source.
I made clone by mercurial:
hg clone http://hg.services.openoffice.org/DEV300 local_DEV300
I started to build following this guide:
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux
Mathias Bauer wrote:
The idea is the unification of pro and non-pro build. We have discussed
that only as an idea to save time in release engineering and a nice
opportunity for additional diagnostic abilities for customer problems,
but maybe it can help in our current discussion also.
Please
