Re: [reSIProcate] future of resip, autotools/git/packaging proposal
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@xxxxxxxxxxxxxxx
> <mailto: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
> <mailto: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
> <mailto:resiprocate-devel@xxxxxxxxxxxxxxx>
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> <mailto: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