hi holger, see comments inline.
all ICLA and CCLA in order?
On 6/2/2010 10:17 AM, Holger Grandy wrote:
Hi Etch Developers,
first of all thank you a lot for choosing us as new committers in the Etch
project.
welcome.
Now we are looking forward to contributing our implementation, which brings me
directly to the topic: :)
yay!
Of course we would like to transfer the code which is currently hosted on
github into the Apache
Etch svn. Afterwards we could close the github repo.
agreed.
That leads to some issues that we would like to discuss with you:
- Build:
The C compiler for Etch can be easily integrated into the current Etch
compiler build,
no problem so far. The C binding runtime libraries are currently meant
to be built either
using Visual Studio, using the GNU toolchain or rake and this build is
not integrated
into the ant based Etch build. Furthermore there are some additional
dependencies for the C binding (APR, APR-ICONV, CUNIT), which are
not part of the Etch distribution and have to be downloaded first. I
would
suggest that we leave that this way for the initial commit and
integrate it into
the official Etch build in a second step. The C binding can be built
for different
operating systems (including but not limited to Win32, Linux, OSX),
using
different compilers. The suggestion is to check in the Visual Studio
projects
and a generic Makefile / Rakefile in the first instance. Afterwards
the build system
can be enhanced and adopted to support different configurations.
the current build is using visual studio pieces to build the c# parts,
with some conditional code included to use mono
when on unix. can you integrate yourself into the ant build like that?
dependences right now come from bits downloaded into a tools directory.
it has been suggested that we move all
such stuff into a tools 1) tools dir (top of etch tree) or a separate
tools project (substructure underneath etch next
to trunk in the etch tree). i think it makes more sense to have it under
the etch tree, as long as it isn't too large.
that brings up a different problem, which is {dependence} x (cross
product) {os build environment}. having one big
build is nice because all things are available for testing, but in
practice is rather unwieldly.
i'm not sure of the current status of trunk. i think there might have
been some work in progress there. 1.1 has branch
made for it, we just need to pump it out. if there is work in progress
on trunk, it might be best to save it off and start
fresh. i will look into that.
- Examples:
The C binding comes with a basic "Hello World" Example which
illustrates
the compatibility between the Java and the C binding. For the future
it would be nice to see the C binding besides the Java and CSharp
binding in the "examples" top-level directory. Of course this requires
the build
issue above to be resolved first.
si, agreed. there should be c examples there.
- Source Code:
I hope it is ok in general if we replace the content of the binding-c
directory
with the code from github and commit that to the ASF svn.
We will add the Apache source code header to all the .c/.h files.
Is there something else we should take care of? Is the Etch svn
already set up
to allow commits from our new apache user IDs?
i guess i'm good with replacing the current c binding with yours. i'm
worried about confusion, though. how would you
feel about retiring binding-c and calling yours binding-c1?
let's resolve the naming issue above and also the "what is trunk" issue.
the only way to know if you have access is to checkout trunk () and see
if you can make a
change, say, to README.txt, make a branch out of it and put your stuff
there. when build issues are resolved and we've looked over the branch,
you'll move it
to trunk.
somewhere in there, before commit to trunk, you run RAT on it.
then we can release as 1.2 (after we release 1.1!)
In a second step we can add the Wireshark plugin source to the Etch repository.
But everything at
its time :)
What is your opinion on those topics?
Another point: could you please check if our apache user IDs are added to the
etch-priv...@... mailing list?
will check.
Looking forward to your answers.
Regards,
Holger and Michael
