Re: [reSIProcate] future of resip, autotools/git/packaging proposal
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