-- replying below to --
From: jan i [mailto:[email protected]]
Sent: Wednesday, December 31, 2014 08:28
To: [email protected]
Subject: platform with minzip, commit or not commit.
Hi All.
I am in serious doubt. I have completed the isolation of minzip with a
platform api in wrapper.c
BUT we have no test cases for DFZipFile.c, so I cannot really be sure I
have done it all correct.
<orcmid>
I assume that you haven't broken the build.
So the question is, what is the policy on making untested changes?
ESPECIALLY when a new API is being introduced.
I would do this in two stages.
1. Do not depend on the wrapper yet, and do not build with it. (If
this creates CMake problems, keep the wrapper on a branch. This
might also help stay out of the way of changes that Kelly is making.)
Commit the wrapper so you are not stuck with uncommitted changes when
you want to sync with the repository.
Allow the wrapper to be reviewed and any tests for it to be devised
before modifying other code to use the wrapper.
2. When cutover to using the wrapper API happens, do that without other
changes. Since the direct use of minizip worked, any failures can
be isolated to introduction of the Wrapper API. This will be a lot
easier to identify and handle.
</orcmid>
I am on my way writing test cases for platform in general, but that will
take another week, and I would like to commit the minizip changes, since it
involved a number of CMakeFiles.txt. Be aware the platform test cases will
not ensure that DFZipFile.c works.
What is the general opinion, should I run the risk and push to master
(hoping you all will help catch the problems, and not put me in the
dungeon) or should I wait until someone provides DFZipFile.c test cases
(which should normally be the case).
Once I have completed test cases for platform, it is my intention to
continue with core, but start with a long discussion.
rgds
jan i
