< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] future of resip, autotools/git/packaging proposal


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.

Regarding autotools, I'm kind of on the fence. I would personally
prefer CMake because it would take care of some of the cross platform
IDE intricacies for us (CMake is a 'makefile' generator: it will
generate makefiles on linux and XCode/Visual Studio projects on
Mac/Win and so on).

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 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.

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