Re: [reSIProcate] future of resip, autotools/git/packaging proposal
I didn't get any further endorsements or concerns about my plans with
autotools, so based on the discussions, I'm going to push ahead like this:
- git can wait: we'll come back to that question later
- I'll finish the autotools stuff on the branch
- those who volunteered can test building the branch
- then I'll merge into trunk, and tests will be repeated
In the meantime, I've also managed to get reTurn into production as part
of Lumicall, http://www.lumicall.org - thanks in particular for all the
assistance from Scott.
On 20/01/12 15:19, Daniel Pocock wrote:
>
> On 20/01/12 03:36, Francis Joanis wrote:
>
>> Hi guys,
>>
>> Cool discussions!
>>
>> Regarding the SCM comment, I'd like to +1 the github suggestion. I
>> really like how it encourages people to 'branch out' and experiment
>> with the code and how you can create 'pull requests' to review and
>> accept changes. They also take care of the hosting for you and are
>> free for open source projects (unless I'm mistaken).
>>
>> I even think that going to github might actually attract more people
>> to the project (but that's an opinion ;)). And if true, that is
>> something big.
>>
> For those unfamiliar with it:
>
> - git and github are not one and the same - we can run git (with
> gitosis) on the existing server, for example
>
> - git is also possible with Sourceforge now
>
> - I have documented the conversion process here, it is easy for anyone
> to run a `trial' of the conversion on their local HDD, it takes a few
> hours while git-svn will just sucks all the commits out of the live SVN
> repo:
>
> http://www.pocock.com.au/migrating-a-sourceforge-project-from-subversion-to-git
>
> - although I'm keen on git, the git decision can be deferred if there is
> no consensus, the autotools/packaging stuff is more critical to meet the
> deadlines for the next Linux distributions
>
>
>> I've had to maintain autotools "makefiles" for some rather large
>> projects in the past and I didn't like it much. Mind you, it might
>> have been because those build files were not clean, but I found CMake
>> extremely flexible and easier to pick-up.
>>
> I've seen many projects, large and small, that make improper use of
> autotools - often because people have copied parts of the configure
> script from another project that was incorrect.
>
> In my branch, I've tried to follow the official autotools strategies
> carefully, e.g. the configure options:
>
> --with-ssl - because libssl is an external component
>
> --enable-dtls (not --with-dtls!) because DTLS functionality is internal
>
> and you can't do --with-ssl=/opt/openssl/some-version/lib - you have to
> do something like
>
> ./configure --with-ssl LDFLAGS=-L/opt/openssl/some-version/lib
>
> This last approach means that some options can be changed when make is
> invoked, e.g.
>
> make CFLAGS="-g"
>
> to override the flags that were set when configure was run.
>
>
>> I am available to test some stuff on Win/Mac/Linux if needed. I also
>> volunteer to get the CMake builds started if we want to try it out.
>>
> A lot of work has already gone into the autotools stuff - would you feel
> the argument for CMake is strong enough to repeat the exercise? I don't
> know enough about CMake to say I am for or against it, but I know that
>
> a) other people are using it successfully (e.g. I've done some work with
> flactag and libMusicBrainz4)
>
> b) packaging systems (like Debian) do have support for it, similar to
> the way they support autotools (e.g. using cdbs on Debian)
> http://build-common.alioth.debian.org/cdbs-doc.html#id2561559
>
>
>
>> Cheers,
>> Francis
>>
>> On 2012-01-19, at 6:28 PM, Jason Fischl <jason.fischl@xxxxxxxxx> wrote:
>>
>>
>>> I am a recent convert to git. I would highly recommend that we migrate
>>> to github. For all of you svn folks out there, you can continue to use
>>> svn to access any code within github.
>>>
>>> https://github.com/blog/966-improved-subversion-client-support
>>>
>>> I realize that many of you guys are resisting the move to git but
>>> really it is well worth learning it. You will really appreciate the
>>> benefits once you learn how to use it.
>>>
>>> Jason
>>>
>>>
>>> On Thu, Jan 19, 2012 at 1:54 PM, Aron Rosenberg <arosenberg@xxxxxxxxxxxx>
>>> wrote:
>>>
>>>> As a GIT user on windows, there is TortoiseGit,
>>>> http://code.google.com/p/tortoisegit/ which is actually the best interface
>>>> to GIT that I have seen, but it is still overkill for resiprocate.
>>>>
>>>> -Aron
>>>>
>>>> On Thu, Jan 19, 2012 at 1:46 PM, Matthias Moetje <moetje@xxxxxxxxxxxx>
>>>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> -Aron
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>