[mapserver-dev] move to github ?

thomas bonfort thomas.bonfort at gmail.com
Fri Mar 23 09:48:59 PDT 2012


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


More information about the mapserver-dev mailing list