[reSIProcate] future of resip, autotools/git/packaging proposal
I'm keen to see some packages happen within the next 6 months so that
they will appear in the next releases of the major Linux distributions
(e.g. the next Debian, Fedora and Ubuntu)
I think this is actually critical for the future of the project, because
it means more people will link their apps to resiprocate, then they will
feed stuff back into the project, and things will snowball from there
It is a chicken-and-egg problem: which came first? I understand there
was previous concern about using autotools because no one is an expert
on the subject. If we had autotools, however, then we will get more
help from packaging experts familiar with autotools, because everything
will be familiar to them. I'm willing to make the effort to get the
project into that position.
What I propose is that we take my autotools branch and proceed like so:
a) prove that it builds with autotools on UNIX and that the Visual
Studio on Windows build is not negatively impacted in any way (done,
although a couple of the configure options are not implemented yet)
b) prove that it runs all test cases (currently only one of them is
built and executed, not hard to copy and paste for the others)
c) prove that it meets the requirements for Debian, Fedora and OpenCSW -
e.g. Debian raised questions about SONAME and ABI, this is documented in
some old threads
http://lists.debian.org/debian-mentors/2009/07/msg00130.html
d) prepare documentation showing
- old build commands and their equivalent with the new system
- steps to make release and build packages
- other useful autotools features that relate to this project
e) merge all recent work from trunk into my autotools branch
f) repeat tests (a), (b) and (c)
g) merge the branch into trunk - completely replace the old configure
script and Makefile system for UNIX
h) make a reSIProcate 2.0 release candidate (I think it is good to jump
to a new version number because of the SONAME and ABI stuff, it makes it
more obvious that there is a new approach)
i) packages go into Debian unstable and OpenCSW catalog
In parallel, we could potentially be doing all this with git, running a
parallel repository (for testing git) up to step (g), and then replacing
SVN. I've already been using git-svn as my local workspace, so I'm
confident that we can introduce git in such a way.
I'm happy to push ahead with these things but I really need to know that
nobody has major objections or alternative proposals
To see it all on a smaller scale, I would be using almost the same
approach that I've used with other software:
https://sourceforge.net/projects/gmod-linux/
https://sourceforge.net/projects/gmod-solaris/
The timescale for this would be about 2-3 months, to ensure people have
time to check things at each stage and object at any step if something
surprises them