[0/5]: patches for clean "make check"
Following this email are five patch sets (whose apply order matters). This is a full roll-up of changes Peter and I worked on last night with some additional updates to get "make check" to fully pass.
1/5: compile cleanups only This is makefile goo for getting "make check" to compile correctly.
2/5: test code changes only This is test-code changes only. No core code changes are needed to make these tests pass "make check".
3/5: core code changes for repr-action-test compiling This is a change to the way core code is layed out in the tree, to help compile repr-action-test more easily. The functions are unchanged.
4/5: core code changes for repr-action-test behavior This changes when an undo session is released, down in simple-session. This lets repr-action-test pass its tests. The only caller to sp_repr_rollback is sp_document_cancel. sp_document_cancel isn't easily callable, since the three calls to it currently would only happen during repr tree breakage in the XML editor. I think this is safe.
5/5: win32 file list updates This is just a final sync of all the above file changes, as seen by the win32 file list building tools.
"make check" finished, but "make distcheck" does not, as streamtest depends on files local to its directory, which is against build rules for "distcheck". I will fix it later, since I made it relocatable in patch #2.
On Sat, 5 Feb 2005 11:50:41 -0800, Kees Cook <inkscape@...62...> wrote:
1/5: compile cleanups only 2/5: test code changes only
Since these don't touch the code, they are OK (provided they work). Please apply.
3/5: core code changes for repr-action-test compiling
This is a trivial move, so if it compiles, it's OK to apply.
4/5: core code changes for repr-action-test behavior This changes when an undo session is released, down in simple-session. This lets repr-action-test pass its tests. The only caller to sp_repr_rollback is sp_document_cancel. sp_document_cancel isn't easily callable, since the three calls to it currently would only happen during repr tree breakage in the XML editor. I think this is safe.
I don't feel this is safe enough. You change not only rollback but also commit. At the very least, I want Mental to OK these changes. And in general, I would prefer a release with some failed tests than with broken core.
5/5: win32 file list updates This is just a final sync of all the above file changes, as seen by the win32 file list building tools.
This one is OK (so long as it compiles).
So, please apply all changes except 4, and try to get Mental's approval on 4.
On Sat, 2005-02-05 at 15:34, bulia byak wrote:
I don't feel this is safe enough. You change not only rollback but also commit. At the very least, I want Mental to OK these changes. And in general, I would prefer a release with some failed tests than with broken core.
Unless the tests are really wrong, failed tests mean broken core by definition...
I will review 4 though.
-mental
On Sat, 05 Feb 2005 18:00:14 -0500, MenTaLguY <mental@...3...> wrote:
On Sat, 2005-02-05 at 15:34, bulia byak wrote:
I don't feel this is safe enough. You change not only rollback but also commit. At the very least, I want Mental to OK these changes. And in general, I would prefer a release with some failed tests than with broken core.
Unless the tests are really wrong, failed tests mean broken core by definition...
Quite often, failed tests mean that they are not updated when the core is changed.
On Sat, Feb 05, 2005 at 07:21:01PM -0400, bulia byak wrote:
On Sat, 05 Feb 2005 18:00:14 -0500, MenTaLguY <mental@...3...> wrote:
On Sat, 2005-02-05 at 15:34, bulia byak wrote:
I don't feel this is safe enough. You change not only rollback but also commit. At the very least, I want Mental to OK these changes. And in general, I would prefer a release with some failed tests than with broken core.
Unless the tests are really wrong, failed tests mean broken core by definition...
Quite often, failed tests mean that they are not updated when the core is changed.
Additional information relevant to the prior-to-review assessment of probability that the test failure indicates a real problem:
In this case, the test triggered an assertion in core. Tests that trigger assertions in core are more likely to indicate a true problem than other test failures.
(Just a probabilistic argument, I haven't reviewed the change in this particular case.)
pjrm.
participants (4)
-
bulia byak -
Kees Cook -
MenTaLguY -
Peter Moulder