[reSIProcate] future of resip, autotools/git/packaging proposal
Aron Rosenberg
arosenberg at logitech.com
Thu Jan 19 12:44:52 CST 2012
I can test the XCode stuff since I maintain it currently. Let me know when
you want me to try it out.
-Aron
On Thu, Jan 19, 2012 at 10:17 AM, Daniel Pocock <daniel at pocock.com.au>wrote:
>
>
> Thanks Scott, Aron
>
> To summarise the feedback I have so far:
>
> - two votes in favor of autotools (no votes against it)
>
> - git: I'm not sure if those are votes against, or just abstentions/more
> detail required?
>
> For XCode: I don't have that on hand: would anyone volunteer to test my
> branch with it?
>
> Alternatively, can someone suggest a strategy to get XCode running
> quickly in a VM? I've heard rumours that it will only install on Apple
> hardware? I currently run a Linux desktop with 12GB and I test Windows
> stuff in Vmware Player, I would want to try and run the Apple stuff the
> same way.
>
> On 18/01/12 19:00, Aron Rosenberg wrote:
> > 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.
> >
> > -Aron
> >
> >
> > On Wed, Jan 18, 2012 at 5:55 AM, Scott Godin <sgodin at sipspectrum.com
> > <mailto:sgodin at sipspectrum.com>> 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 at pocock.com.au
> > <mailto:daniel at pocock.com.au>> 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 at resiprocate.org
> > <mailto:resiprocate-devel at resiprocate.org>
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at resiprocate.org
> > <mailto:resiprocate-devel at resiprocate.org>
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> >
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at resiprocate.org
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20120119/49ac14f9/attachment.htm>
More information about the resiprocate-devel
mailing list