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

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


I'm just going to revive the git discussion now that we are over the
autotools hurdle

Motivation: we've had two other major open source projects (FreeSWITCH
and Asterisk) looking at reSIProcate, both of them would benefit from
the way that git allows easy branching and forking.  FreeSWITCH
explicitly asked for git, Asterisk indicated they may need to fork
during development.

Timing: if it does happen, it probably needs at least 1 month for trial,
checking tools, etc, but should also be done at least 2-3 months before
1.9 release.  So between January-March seems like a possible window for
this.

git hosting: public hosting is less controversial than with SVN, because
with git, everybody has a full clone of all commits.  So if the host
goes away (or starts charging money), we don't lose anything.  github
seems to offer a nice variety of features for web management, code
review, etc, so I'd propose we try it out.

Process: I've written a script to automate the conversion


https://svn.resiprocate.org/viewsvn/resiprocate/main/build/svn2git.sh?view=markup

and I've done a trial run into github:

    https://github.com/resiprocate/resiprocate


Action items:

- we need to complete the svn-authors.txt file (git needs email
addresses), I've done most of it, but some login names are ambiguous or
I don't have email addresses for them:

https://svn.resiprocate.org/viewsvn/resiprocate/main/svn-authors.txt?view=markup

- for example, I see two logins `matthias' and `moetje', are they both
the same Matthias?  What about `adam' and `adamr'?

- repository structure:
  * do we need all the branches in git?
  * should some things go into separate repositories (using git submodules)?
  * same questions for all the tags

- tools:
  * what tools do people use (e.g. for SVN access in Eclipse, Visual
Studio)?
  * testing similar tools for git
  * adding details on a wiki perhaps







On 23/02/12 13:27, Daniel Pocock wrote:
> 
> 
> 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
>>   
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel