Hi Frank,
I am indifferent regarding whether assertions should abort, but please
let me comment your suggestions below:
On 02/12/10 09:11, Frank Schoenheit, Sun Microsystems Germany wrote:
Hi,
issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142)
requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and
friends) to abort if their condition is not met. The current behavior is
that the assertion text is reported to the user, usually by a message box.
All of the above applies to non-product builds only, in particular, the
request, as I understand it, is *not* to extend assertions to product
builds.
Since this is a controversial topic, I think we should discuss it in a
wider audience before actually implementing the change - so, let's get
the party started ...
[...]
The problem which the issue tries to address, however, is still valid,
and highly legitimate, in my opinion. Assertions are a cheap and
already-existing measure to improve our product quality (and in my
personal opinion, both the 3.1 and the 3.2 release have shown that we
should improve here). Still, too few people use non-product builds,
which means new assertions are introduced, which means more people are
scared away from using non-product builds ... which renders assertions
nearly useless.
So, my suggestions would be the following (admittedly, they're more on a
social level, than on a technical one, and thus harder to enforce):
- Developers should use non-product builds *only*. That's a very
apparent measure, still, a lot of people don't do. If you ask why,
often the answer is "it's unusable 'cause of the many assertions".
Hmm?
- QA should use non-product builds *only*. Yes, I am not kidding about
this. An assertion which fails indicates a *bug*, that's the very
original intention of assertions: report bugs. Speaking strictly,
QA which refuses to use non-product builds refuses to do their job,
which at least in parts consists of finding bugs.
Here I strongly disagree. Assertions should be fought before a CWS sees
QA. That's something developers should do. Testers have to test what the
customer will get.
- Report assertions as you find them, and fix them as you get the issues
assigned. Give them high priority, as every assertion might be a
little effort for you to fix, but it is a lot of paint for a lot of
other people as long as it is not fixed.
+1
- Get *serious* management backup for the three previous items.
(<insider>That's something which is highly missing since MA left years
ago :) </insider>)
- Provide non-product builds for release code lines, too. At least do so
much longer than we did with OOO320 (This item strictly applies to
Sun-internal workflows.):
For OOO320, we stopped providing non-product builds at branch-off day,
which was about half a year before the product was actually released.
During a significant part of this time, there still happened heavy
development on that code line, which is prone to introducing new
assertion failures, going unnoticed in product builds.
That's not correct. OOO320 started end of September 2009. Branch date
was code freeze, afterwards only stopper bugs got accepted.
We once decided to restrict non-product builds for code lines where
active development happens, and I still believe that is a good decision.
Release branches as we currently handle them are definitely not the
place for "heavy development".
- Basically: Understand that assertions are not there to hinder your
work. They exist to help you (at pretty low costs) finding bugs in
your code, and thus improving our product - which is something we all
should be interested in, right?
- Consequently, *use* assertions when writing new code. There's no such
thing as "too much assertions" in the code - as long as they never
fire, of course :)
Ciao
Frank
Rüdiger
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
