corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: platform with minzip, commit or not commit.
Date Wed, 31 Dec 2014 17:55:27 GMT
On 31 December 2014 at 18:46, Dennis E. Hamilton <>

>  -- replying below to --
> From: jan i []
> Sent: Wednesday, December 31, 2014 08:28
> To:
> 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.
+1, this is really something we need to form a policy about.....I am scared
about what a stray commit can do.

>    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.
I cannot follow you here. I cannot commit the changes without the wrapper,
then it will not build, secondly we have no place where I can make
wrapper.c available apart from the development branch.

>     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.
That is exactly what I have prepared now.

Wrapper.c + DFZipFile.c (the only consumer) and the needed CMakeFile.txt

Errors can be in either DFZipFile.c or wrapper.c. Since I moved code from
one into the other I need to commit both at the same time.

But I listen carefully to the arguments, because this is a really important
matter for the future. Of course I believe it works, but so will any
developer in the future, and we are all just humans.

thanks for commenting.
jan i.

> </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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message