[mapserver-dev] move to github ?

Tue Mar 27 12:25:59 PDT 2012

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