[mapserver-dev] move to github ?

[Umberto Nicoletti]

+1 on github

On Tuesday, March 27, 2012, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20120328/2e3a6d34/attachment-0001.html