<div dir="ltr">++ from me :-)<div><br></div><div>I would say that it is best to transfer it, and to put the transfer as far back in time as possible, i.e. do it now so that the change becomes less disruptive in the future.</div>

<div><br></div><div>I dislike SVN, and find git acceptable, and combined with GitHub making it quite useful.</div><div><br></div><div>Music21 saw the light this year -- you can study how they handle it by keeping releases available on GoogleCode, but moving the repository activity to GitHub:</div>

<div>   <a href="https://github.com/cuthbertLab/music21">https://github.com/cuthbertLab/music21</a><br></div><div>   <a href="https://code.google.com/p/music21">https://code.google.com/p/music21</a></div><div><br></div><div>

In other words, you can keep multiple copies, but only do version control on GitHub -- copying over the contents to GoogleCode as desired at every significant change, such as releases.</div><div><br></div><div>GitHub has a pretty good system for hosting webpages, here is the new Humdrum documentation website set up at the MEC Hack day by Dan Shanahan fairly quickly from the old documentation website (still under construction):</div>

<div>    <a href="http://www.humdrum.org">http://www.humdrum.org</a></div><div><br></div><div><br></div><div>-=+Craig</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On 28 May 2014 11:54, Andrew Hankinson <span dir="ltr"><<a href="mailto:andrew.hankinson@mail.mcgill.ca" target="_blank">andrew.hankinson@mail.mcgill.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Ok.<br>
<br>
At the moment we have a couple contributions pending on GitHub. Here’s what I would suggest as a way forward:<br>
<br>
1) We temporarily disable the GitHub Issues and maintain the Google Code issues as the primary issue tracker.<br>
2) We keep the GitHub account open. It has already been useful in encouraging contributions, and I would not want to lose that.<br>
3) I will ensure that contributions are bi-directional. That is, if someone commits to GitHub, I can contribute it in Google Code, and if a change is made in Subversion, I will update the GitHub account.<br>
<br>
Obviously #3 is not a long-term solution, but the tools support this type of bi-directional syncing so it’s not a particularly onerous task.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Andrew<br>
</font></span><div class="im HOEnZb"><br>
On May 28, 2014, at 2:29 PM, Johannes Kepper <<a href="mailto:kepper@edirom.de">kepper@edirom.de</a>> wrote:<br>
<br>
> Given that almost everyone argues in favor of moving there, and even Perry says he's not aversed, I think we should go there. But I also think that Perry's argument is important. During the members meeting, Raffaele pointed out that the organizational structure should be reflected into the rights of the versioning system. Therefore, I would second the two of them and suggest to wait with the transition until we have a board in place. This gives us time to prepare both the data and ourselves…<br>


><br>
> just my 2c…<br>
><br>
> Johannes<br>
><br>
><br>
><br>
> Am 28.05.2014 um 20:19 schrieb Roland, Perry D. (pdr4h) <<a href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>>:<br>
><br>
>><br>
</div><div class="HOEnZb"><div class="h5">>> I'm not opposed to hosting MEI on GitHub.  However, I don't want to rush headlong into the switch.  As I see it, there is good reason to stay the current course during the determination of MEI's organizational structure.  Once a new Board/Technical Group is in place, it/they/we can take up the GitHub vs. SVN discussion.<br>


>><br>
>> --<br>
>> p.<br>
>><br>
>><br>
>><br>
>>> -----Original Message-----<br>
>>> From: mei-l [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] On Behalf Of<br>
>>> Eleanor Selfridge-Field<br>
>>> Sent: Tuesday, May 27, 2014 6:15 PM<br>
>>> To: Music Encoding Initiative<br>
>>> Subject: Re: [MEI-L] Hosting MEI on GitHub<br>
>>><br>
>>> +1 GitHub<br>
>>><br>
>>> Eleanor<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: mei-l [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] On Behalf Of<br>
>>> Andrew Hankinson<br>
>>> Sent: Friday, May 23, 2014 10:15 PM<br>
>>> To: Music Encoding Initiative<br>
>>> Subject: [MEI-L] Hosting MEI on GitHub<br>
>>><br>
>>> Hello,<br>
>>><br>
>>> At the MEI Hack Day today we discussed the pros and cons of moving MEI<br>
>>> development from Google Code hosting<br>
>>> (<a href="https://code.google.com/p/music-encoding/" target="_blank">https://code.google.com/p/music-encoding/</a>) to GitHub. Both of these tools<br>
>>> are used to share and collaborate on open source projects. However, it was<br>
>>> felt by some that GitHub offers more possibilities for easy collaboration<br>
>>> and participation than the Google Code platform, and as such we should<br>
>>> consider moving our hosting platform.<br>
>>><br>
>>> To see if this was possible we experimented with moving both the code<br>
>>> (and<br>
>>> its complete version history) and our issue tracker. The results of our<br>
>>> testing are available here:<br>
>>> <a href="https://github.com/music-encoding/music-encoding" target="_blank">https://github.com/music-encoding/music-encoding</a>. All of the code and<br>
>>> issues seem to have been migrated without a problem.<br>
>>><br>
>>> Before we make the final decision to switch, however, we wanted to put it<br>
>>> to the community to gather any questions or comments about this switch,<br>
>>> and to give people an opportunity to voice any concerns they may have.<br>
>>><br>
>>> After a period of discussion the technical team will make a final decision<br>
>>> and notify the community. This will not be a long period of discussion,<br>
>>> since it will be hard (and confusing) to manage two issue trackers and<br>
>>> repositories, so please do not wait.<br>
>>><br>
>>> Thank you,<br>
>>> -Andrew<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> mei-l mailing list<br>
>>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>>><br>
>>> _______________________________________________<br>
>>> mei-l mailing list<br>
>>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>><br>
>> _______________________________________________<br>
>> mei-l mailing list<br>
>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div></div></blockquote></div><br></div>