[mapserver-dev] move to github ?

Wed Mar 28 00:57:20 PDT 2012

and for completeness, here is a trac instance pointing to a git
checkout, with updated ticket rXXXX refs (in comments only, for now):

http://www2.terriscope.fr:8000/trac

--
thomas


On Tue, Mar 27, 2012 at 21:25, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> I'm currently importing the trac tickets into github. We should be
> able to keep ticket numbers intact (could be used to write rewrite
> rules for trac tickets). The references to the commits (r1234
> notation) in summaries and comments are converted to git sha1s with
> links to the actual commit.
>
> The ticket assignee isn't correct but will be (I'm not activating this
> yet to avoid email notifications). All the tickets and comments will
> be marked as if they were added by me, however the userid of the
> original poster is added to the body of each of these elements.
>
> the link to the full project is https://github.com/tbonfort/mstmp
>
> the branches aren't yet pushed there but that would be the case later on.
>
> Given that Daniel's reticences towards history are resolved by this
> outcome, I would like to get this moving again with new comments, or
> start voting asap (I have spent alot of effort on this already, and
> don't have much free time left to do the actual transition)
>
> regards,
> thomas
>
> On Fri, Mar 23, 2012 at 17:48, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>> On Fri, Mar 23, 2012 at 17:04, Daniel Morissette
>> <dmorissette at mapgears.com> wrote:
>>> On 12-03-23 7:37 AM, thomas bonfort wrote:
>>>>
>>>> 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
>>>>
>>>
>>> Hi Thomas,
>>
>> Hi Daniel,
>> thanks for your answer
>>
>>>
>>> Thank you for putting this together and for your efforts trying to make old
>>> timers (such as me) see the light. My silence of the last few days was
>>> because I was swamped with other stuff, and not due to a lack of interest.
>>>
>>> First of all, as I already said in Seattle, I am a happy Trac/SVN camper and
>>> don't see a need to move, but OTOH I am always open to being shown better
>>> ways to do things, that's why I like to have guys like you Howard and Alan
>>> around and poking me, so I will not get in your way as long as my primary
>>> concerns below can be addressed... I'll even work with you to find
>>> solutions.  :-)
>>>
>>> (And yes I still miss Bugzilla as was pointed out on IRC recently... I
>>> always will until a better tool shows up ;-) , and even if I am used to Trac
>>> today and prefer it for some aspects, it's seriously lacking on some stuff
>>> that Bugzilla provided several years ago such as powerful search features
>>> and ticket dependencies.)
>>>
>>> Ok, so back to the git topic. My primary concerns are:
>>>
>>> P1 - Maintain complete history of commits and tickets
>>> P1 - Ability to migrate in a few years
>>>
>>> And
>>>
>>> P2 - Offsite backups/mirrors
>>> P2 - Reliability of the service
>>> P3 - Maintain commits vs tickets references in the tools we use
>>>
>>> The availability of new features or the ease of use of the new workflow
>>> don't worry me too much. I trust that you would not be spending all that
>>> energy if the proposed approach was not better in general.
>>>
>>>
>>> Please let me elaborate on each concern:
>>>
>>> * P1 - Maintain complete history of commits and tickets
>>>
>>> I do care a lot about maintaining the history of the project for a
>>> combination of reasons:
>>>
>>> - Practical reasons: I go back in ticket and commit history very often when
>>> I'm troubleshooting problems, to understand why/when something was changed
>>> or why it was implemented in a given way. History is also useful to identify
>>> whether a given feature was available or broken in e.g. version 4.10 or only
>>> in 5.2. Losing this is not an option for me.
>>>
>>> - Legal reasons: The complete history of commits and tickets can sometimes
>>> be used to track down the provenance of a given block of code and confirm
>>> our rights to use it. And the other way around, the history could even be a
>>> way to demonstrate that MapServer had feature or algorithm x or y
>>> implemented before someone else filed a patent on that feature for instance.
>>>
>>> - Coolness factor: It's just cool to be able to replay 12 years of commit
>>> history. ;-)
>>
>> History of the code: everyone will have it in their checkout, offline,
>> so you'll have the coolness factor of replaying your twelve year
>> history on a plane. As such everybody also has a backup of the whole
>> history, which does not preclude maintaining a more official backuping
>> system elsewhere.
>>
>> History of the tickets: is keeping the trac instance online a viable
>> option for the ticket history? Basically put, if you need the full
>> ticket history synchronized with the git code and new tickets, this
>> precludes us from using github.
>> For me, the ticket history is *the* point that we need to sort out
>> before moving. it's one of:
>> - github + clean slate
>> - trac + ticket history
>>
>>>
>>>
>>> * P1 - Ability to migrate in a few years
>>>
>>> Git (and github) may be the cool tool of the day (year?), but I have no
>>> doubts that they will be superseded by something even cooler in a few years.
>>> It is very important to maintain our freedom and ability to migrate to a new
>>> system with full history (commits and tickets) whenever we see fit.
>>
>> For the code, see above. For the tickets, the http api does not
>> prevent us from backuping open issues, there are some existing
>> projects that do this. You will be left in the same state as we are in
>> with trac now: the data is here but needs significant massaging to
>> transfer it to a new system.
>>
>>>
>>>
>>> * P2 - Offsite backups/mirrors
>>>
>>> I think that maintaining daily offsite backups of the repository and tickets
>>> is critical, whether we host at OSGeo or elsewhere. Maintaining one or more
>>> live mirror(s) would be a nice to have but not as critical.
>>>
>>> I am concerned that github could either shut its doors or be bought out by a
>>> large corporation that would make it less open-friendly or less available
>>> than it is today. Offsite backups could mitigate that concern.
>>
>> c.f. above. the fact that multiple people own the ful history of the
>> project makes it much more difficult for the company to start
>> extorting with the reason that they are your sole data guardian.
>>
>>
>>>
>>>
>>> * P2 - Reliability of the service
>>>
>>> Of course we want whatever service we use to have the best possible uptime
>>> and performance.
>>>
>>> I will admit that I am a bit worried that github like any free service might
>>> eventually suffer the same performance issues that have plagued sourceforge.
>>> OTOH, we've had our share of downtimes with OSGeo servers as well.
>>>
>>> I tend to prefer keeping control on the hosting (i.e. hosting at OSGeo), but
>>> I understand the value in letting another org take care of this for us.
>>>
>>> I guess maintaining good offsite backups guarantees our ability to migrate
>>> in case the option that we chose starts having reliability or performance
>>> problems.
>>
>> I think this is a non-issue for me. Both are susceptible to downtimes,
>> we'd have to look into much pricier solutions if we cannot tolerate
>> that. (and with git you can continue commiting and branching when
>> you're offline :) )
>>
>> --
>> thomas
>>
>>>
>>> * P3 - Maintain commits vs tickets references in the tools we use
>>>
>>> This is a lower priority, but it would be nice if we could maintain the
>>> commits vs tickets references for the full history. (I realize that there
>>> would be some work involved and could look at how Mapgears could contribute)
>>>
>>>
>>> That's it. No strong or religious positions on my part. I'm open to change
>>> as long as the concerns above can be addressed, one way or another.
>>>
>>> Daniel
>>> --
>>> Daniel Morissette
>>> http://www.mapgears.com/
>>> Provider of Professional MapServer Support since 2000
>>>
>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev