[mapserver-dev] move to github ?

[Angelos Tzotsos]

Hi all,

please take a look at this project:

http://rhodecode.org/

It could be used as a local alternative to github (it supports mercurial 
and git)

Regards,
Angelos

On 03/19/2012 07:26 PM, Alexandre Dube wrote:
> Hi,
>
>   I don't want to spoil anything, but Github was hacked a few weeks 
> ago [1].  Also, I've not been using it much, but every time I did I 
> ran into "server problems" while navigating the pages.  I was forced 
> to reload the pages until it finally worked, which took a while every 
> time.
>
>   Personally, I would much prefer the (1) option, or if any 
> alternative to Github for git exists that could be hosted then that 
> would be even better.  Just my 2 cents, though.
>
> Kind regards,
>
> Alexandre
>
> [1] 
> http://www.extremetech.com/computing/120981-github-hacked-millions-of-projects-at-risk-of-being-modified-or-deleted
>
>
> On 12-03-19 12:52 PM, thomas bonfort wrote:
>> Hi devs,
>>
>> I would like to get the ball rolling and start talking about switching
>> from svn to git, and trac to github. I don't think it's worth
>> enumerating the advantages of git over svn for collaborative
>> development, but there are a few issues that will probably spark
>> discussion.
>>
>> I believe we have multiple options, which mostly revolve around
>> keeping our actual trac instance, or moving entirely to github.
>>
>> option 1: host our own git server, keep our current trac instance.
>> this option is probably the less disruptive, and prevents us from
>> relying on github. But it is also the option that prevents us from
>> using the nifty features github offers, namely pull requests, commit
>> commenting, online editing for quick fixups, ...
>>
>> option 2: host the code at github, keep our trac instance. probably
>> not a good option, as we'd have to juggle between trac features and
>> github features
>>
>> option 3: host code and tracker on github, import all trac tickets to 
>> github.
>>
>> option 4: host code and tracker on github, starting with a clean slate
>> and having users migrate the tickets that are still current.
>>
>> My personal preference is option 4. Option 3 will probably be a
>> consequent task, for little added value imho (as a large number of our
>> open tickets have become invalid with subsequent releases). The
>> OpenLayers team chose to go with a mix of option 2 and option 4, and
>> will probably go with option 4 only, given the advantages offered by
>> github.
>>
>> any other options? what are your thoughts?
>>
>> regards,
>> thomas
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>


-- 
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos