[mapserver-dev] move to github ?

Fri Mar 23 04:37:08 PDT 2012

I've written RFC84:

http://mapserver.org/development/rfc/ms-rfc-84.html

(not published yet, should appear soon, for now:
http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-84.txt)

/me ducks

--
thomas

On Fri, Mar 23, 2012 at 04:32, Lime, Steve D (DNR)
<Steve.Lime at state.mn.us> wrote:
> I'll support the more knowledgeable and active devs on this one and adapt as necessary. I probably didn't want to move away from cvs to svn when that change happened.
>
> That said, seems that a small RFC would be in order here to help formalize the process.
>
> Looking back at the discussion and the 4 options Thomas originally proposed. I'd prefer 3/4- github with *selected* open tickets. If there's a hosted solution that's better than github then cool but I'm thinking it would be nice to be out of as much infrastructure administration as possible.
>
> Steve
>
> ________________________________________
> From: thomas bonfort [thomas.bonfort at gmail.com]
> Sent: Thursday, March 22, 2012 5:43 AM
> To: Lime, Steve D (DNR)
> Cc: MapServer Dev Mailing List
> Subject: Re: [mapserver-dev] move to github ?
>
> On Thu, Mar 22, 2012 at 11:10, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>> Here's my workflow from the last couple of days, when using github to
>> hack on the mapcache source, hoping the strengths of the solution will
>> become clearer.
>>
>> I started working on adding a tokyocabinet cache backend to mapcache,
>> so I create a branch for it:
>>
>> # git checkout -b tokyocabinet
>>
>> My source tree is now in this new feature branch, I hack away and add
>> the new feature, optionally comitting along the way once I reach local
>> milestones. Once the initial implementation is up and running, I
>> commit it, and can optionally push it back to the github server for
>> others to try it:
>>
>> # hack, hack, hack
>> # git add lib/cache_tokyocabinet.c include/mapcache.h   // add the
>> modified files to the list of files that need comitting
>> # git commit -m "initial implementation of a tokyo cabinet cache backend"
>> # git push origin tokyocabinet  // publish my tokyocabinet branch, it
>> is not merged to the trunk yet
>>
>> I then start working on optimizing the cache code, by adding a
>> connection pool. A trac notification comes in signaling a bug in
>> mapcache trunk, so I switch to the trunk ("master") branch of mapcache
>> and fix the bug.
>>
>
> As someone promptly replied to me offlist on this part, I will correct
> this: You don't hack directly on the master, you create a branch. svn
> reflexes are hard to loose :). To my defense, the fix was a single
> character typo change, so I did not branch. Any non trivial bug fixing
> would go from
>
>> # git checkout master
>> # debug, hack
>> # git add -A  //add all changed files to the commit list
>> # git commit "fix bug #1234"
>> # git push origin master  // publish changes to the github repository
>
> to
> # git checkout -b bug1234
> # debug, hack
> # git add -A  //add all changed files to the commit list
> # git commit "fix bug #1234"
> # git checkout master
> # git merge bug1234
> # git push origin master  // publish changes to the github repository
>
> This allows you to cleanly work on any other stuff, should the fixing
> of bug 1234 take longer than a few minutes.
>
>
>>
>> # git checkout tokyocabinet  // return to hack on my new feature
>>
>> I continue hacking on my connection pool, unfortunately the resulting
>> code is unstable, tokyocabinet does not like concurrent connections. I
>> create a new branch for this code so I can come back later to hack on
>> it when I have the time.
>>
>> # hack hack hack, fail to get something satisfactory
>> # git checkout -b tokyocabinet-connectionpool  //create a new branch
>> # git add lib/cache_tokyocabinet.c
>> # git commit -m "initial implementation of a connection pool for
>> tokyocabinet, still not working due to concurrent access issues"
>> # git push origin tokyocabinet-connectionpool   //publish the code.
>> this is optional, but I want my test code to be backed up somewhere
>>
>> After testing some more, the initial version of the tokyocabinet code
>> is stable enough to be included in the master
>>
>> # git checkout master  //switch to "trunk"
>> # git merge tokyocabinet
>> # git push origin master  //publish the changes
>>
>> I don't need the tokyocabinet branch anymore, so I delete it
>>
>> # git branch -D tokyocabinet  //delete locally
>> # git push origin :tokyocabinet  //also delete the published branch on
>> the github server
>>
>> I am now in a state where I can come back to the
>> tokyocabinet-connectionpool branch some day. Note that all the
>> commands I used beforehand where instantaneous, except for the "push"
>> ones which required a network access to publish my changes. During all
>> the hacking phases, I could have merged incoming changes from other
>> devs to my branches with:
>>
>> # git pull origin master   //equivalent to svn up in trunk
>> # git merge master  //merge the changes to my hacking branch
>>
>> --
>> thomas
>>
>> On Tue, Mar 20, 2012 at 18:23, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>>> On Tue, Mar 20, 2012 at 17:32, Lime, Steve D (DNR)
>>> <Steve.Lime at state.mn.us> wrote:
>>>> I'm kind of in the same boat as Frank and am not up on the differences and/or benefits of one versus the other. Seems like that's a worthy discussion...
>>>
>>> I'll try to give some points which are the most important to me. I'm
>>> far from knowing git well enough to list all of them so if others want
>>>  to chime in please do.
>>>
>>> git alone (without github):
>>> - you get the whole project history, without needing to go online
>>> - offline commits mean you can much more easily create revision points
>>> when you're on the road and are working on multiple tasks. I can't
>>> count the number of experimental patches I have thrown away because I
>>> needed to fall back to a clean trunk when fixing an urgent ticket.
>>> - the workflow is somewhat changed: you create a branch (no need to be
>>> online) as soon as you start working on a new feature, or on fixing a
>>> given ticket. Switching from one branch to another is done instantly,
>>> which means you can work on parallel tasks very easily, without
>>> risking that your changes interfere with one another. three way merges
>>> make merging code from one branch into another much less painfull than
>>> with svn+patch
>>> - all this means that we also don't have to go through the
>>> feature-freeze where all development is halted in trunk while we
>>> release. You just merge back the fixes of the release branch back into
>>> the trunk (called master by convention).
>>>
>>> github:
>>> - pull requests (along with easy branches) make applying user-supplied
>>> fixes much easier.
>>> - code commenting (add comments directly aside a specific line in a
>>> changeset) makes collaboration much lighter than having to create a
>>> full email recapitulating the context.
>>> - online code edition, typically for quickly committing a typo fix.
>>>
>>> Aside from that, all the people I know who have switched from trac+svn
>>> to git+github would never move back to the old solution. The git
>>> learning curve is quite steep (although using it the same as svn isn't
>>> very challenging) but I think very well worth it. Of course, that is
>>> provided you hack frequently on the code.
>>>
>>> --
>>> thomas
>>>
>>>>
>>>> Steve
>>>> ________________________________________
>>>> From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] on behalf of Frank Warmerdam [warmerdam at pobox.com]
>>>> Sent: Monday, March 19, 2012 9:39 PM
>>>> To: thomas bonfort
>>>> Cc: MapServer Dev Mailing List
>>>> Subject: Re: [mapserver-dev] move to github ?
>>>>
>>>> On Mon, Mar 19, 2012 at 9:52 AM, thomas bonfort
>>>> <thomas.bonfort at gmail.com> wrote:
>>>>> any other options? what are your thoughts?
>>>>
>>>> Thomas,
>>>>
>>>> Since you ask - I'm happy with the way things are!
>>>>
>>>> Best regards,
>>>> --
>>>> ---------------------------------------+--------------------------------------
>>>> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>>>> light and sound - activate the windows | http://pobox.com/~warmerdam
>>>> and watch the world go round - Rush    | Geospatial Software Developer
>>>> _______________________________________________
>>>> mapserver-dev mailing list
>>>> mapserver-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>