<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">As I see it, no one has yet provided a reason to move to Git and GitHub other than some version of “I dislike SVN” or “it’s what everyone is using these days”. It seems to me
that SVN and Git perform the same basic function, so the so-called advantages of Git seem to me to be more a matter of personal preference than functional difference and more complicating than helpful since a new vocabulary is required to describe existing
processes and functionality.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">Some say a significant advantage of Git is that it will encourage more participation in the revision of MEI. I’m not sure that will solve more problems than it creates. Is there
really a huge group of contributors looking to modify the MEI source whose needs aren’t met by the current system? Even if such a group exists, is it desirable to allow frequent changes to mei-source? One of the reasons for using ODD is to control the modification
process so that changes can be reviewed and incorporated after careful thought. If a large group can simply change mei-source.xml file at will, the customization process as test bed loses its effectiveness.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">The “</span><span style="font-family:"Calibri","sans-serif"">do it now so that the change becomes less disruptive in the future”</span><span style="font-family:"Calibri","sans-serif";color:black">
argument sounds a lot like a sales pitch that begins with “This offer is only good for today”. If it’s a good idea to buy that car or move to Git today, it will still be a good idea tomorrow, next week, or even next year. In fact, the move could become more
desirable as time goes on, but we won’t know that until we’ve had some time to think it over.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">Maintaining multiple repositories seems to me like inviting trouble unless one can guarantee that the information flow is always from GitHub to GoogleCode. I assume that if someone
forgets and modifies the SVN repo, at best any changes would be lost and at worst conflicts would be created on a level that could be very difficult to resolve. Even if the workflow can be guaranteed and we don’t care about changes in the SVN repo getting
lost, in the “version on GitHub and copy to GoogleCode” scenario, then GoogleCode becomes redundant. But creating this redundancy solely as an argument to eliminate GoogleCode/SVN isn’t valid logic. If copies cause trouble, don’t make copies.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">We already have a web presence at music-encoding.org so I fail to see how hosting webpages on GitHub is beneficial. That would simply dilute the recognition of music-encoding.org
as the home of MEI.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">Just my 2 cents,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">p.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> mei-l [mailto:mei-l-bounces@lists.uni-paderborn.de]
<b>On Behalf Of </b>Craig Sapp<br>
<b>Sent:</b> Wednesday, May 28, 2014 5:49 PM<br>
<b>To:</b> Music Encoding Initiative<br>
<b>Subject:</b> Re: [MEI-L] Hosting MEI on GitHub<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">++ from me :-)<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I dislike SVN, and find git acceptable, and combined with GitHub making it quite useful.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <a href="https://github.com/cuthbertLab/music21">https://github.com/cuthbertLab/music21</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <a href="https://code.google.com/p/music21">https://code.google.com/p/music21</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <a href="http://www.humdrum.org">http://www.humdrum.org</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-=+Craig<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 28 May 2014 11:54, Andrew Hankinson <<a href="mailto:andrew.hankinson@mail.mcgill.ca" target="_blank">andrew.hankinson@mail.mcgill.ca</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">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 style="color:#888888"><br>
<span class="hoenzb">-Andrew</span></span><o:p></o:p></p>
<div>
<p class="MsoNormal"><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>
>><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">>> 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><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>