My code contributions have been quite small so far, but I agree with Scott and Aron: Yes for autotools, No to move away from SVN. I know about the advantages of Git, but I think reciprocate development wouldn’t benefit much from it. The volume of changes is low, so is the number of contributors. IMHO there is no need for hierarchical/distributed or local branches. What remains would be the time to install and learn something new. A look at http://help.github.com/win-set-up-git/ shows that it’s probably a lot more complicated than just installing Tortoise SVN ;-) Best regards, Matthias Moetje From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Aron Rosenberg
Sent: Mittwoch, 18. Januar 2012 19:00
To: resiprocate-devel@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] future of resip, autotools/git/packaging proposal I second Scott's view that Git would be overkill here for the project. I am all for the autotools integration. Keep in mind that Apple Mac and Apple iOS builds use XCode projects so those will need to be tested to make sure they don't break as well with the autotools changes.
On Wed, Jan 18, 2012 at 5:55 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote: Hi Daniel, First off, thanks for taking such a keen interest in improving resiprocate. I don't have a strong opinion on the build tools stuff, as I've mainly been building in Windows over the years. However I have seen in some previous projects a need to implement autotools builds for resip - so it sounds like it could be a good thing to me. On the GIT vs SVN topic, I would have to agree with Adam Roach's post from a few weeks back. I think git may end up being a barrier to use, especially within the Windows community, due to it's increased complexity. Also I'm not really seeing the advantages of moving to GIT. I hope others will respond with their opinions as well. : ) Scott Godin On Wed, Jan 18, 2012 at 7:50 AM, Daniel Pocock <daniel@xxxxxxxxxxxxx> wrote:
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
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
|