Am 12.02.2010 13:44, schrieb Stephan Bergmann:
On 02/12/10 13:38, Christian Lippka wrote:
Am 12.02.2010 13:28, schrieb Stephan Bergmann:
On 02/12/10 12:34, Christian Lippka wrote:
But you can never be 100% sure that you didn't introduced assertions
since you can't check every code path there is that may be affected
by your changes. Therefore assertions will pop up in the master and
an abort will render non pro unusable so people will stop introducing
them.
If with "introducing them" you mean "introducing assertions:" People who
write extremely bad code (code that contains programming errors and
additionally lacks assertions, that would allow to identify those
programming errors more easily) have to be handled in some way, yes.
But, if left unhandled, those people will write bad code whether or not
assertions abort.
If with "introducing them" you mean "introducing [i.e., using] non-pro
builds:" The logic of preferring a pro over a non-pro here, as, upon
encountering a programming error the pro carried on regardless (and
potentially silently corrupted data, or silently gave wrong results)
whereas the non-pro failed fast, looks faulty to me.
No I ment you change something in the code which causes an assertion
to fire.
???
Stopping people from "chang[ing] something in the code which causes an
assertion to fire" (in other words: stopping people from introducing
programming errors) would be great, no? What am I missing?
Let me re explain it :-) I compared warning free code which breaks
the build to assertions which schould not break the build.
If you change code at one place, you may cause a compiler warning
at another place. This is easy to catch if you do a complete
build so chances are high you will not introduce build breaker
in the master. If this would not be the case, release eng. would
disable warning free code rather sooner than later since the get
tired to fix other peoples build breakers.
If you change code at one place, you may cause an assertion to
trigger at another place. But unlike compiler warnings there
is no way to check the complete office for assertion automaticly.
Therefore assertions will pop up in the master and annoy others,
causing sooner or later that all people use only pro again. FAIL.
Therefore assertions will and do pop up in the master. which is
no problem if they get fixed in time. If there is a milestone
that has to many assertions, you can already redirect them
in a window (right after you wrote the author of that assertion
a P1 issue).
If this is still not understandable, I will draw you a flow chart
on monday at your office :-)
Before anyone argue, yes you can introduce compiler warnings
on other plattforms. Since at least most sun developers do
3-4 plattforms on each cws before they give them to QA, this
is a minor issue.
Christian.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
