[mapserver-dev] move to github ?

[Daniel Morissette]

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,

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


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


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


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

* 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