[MEI-L] Hosting MEI on GitHub

Thu May 29 00:51:36 CEST 2014

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.

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.

The “do it now so that the change becomes less disruptive in the future” 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.

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.

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.

Just my 2 cents,

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp
Sent: Wednesday, May 28, 2014 5:49 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Hosting MEI on GitHub

++ from me :-)

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.

I dislike SVN, and find git acceptable, and combined with GitHub making it quite useful.

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:
   https://github.com/cuthbertLab/music21
   https://code.google.com/p/music21

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.

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):
    http://www.humdrum.org

-=+Craig

On 28 May 2014 11:54, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>> wrote:
Ok.

At the moment we have a couple contributions pending on GitHub. Here’s what I would suggest as a way forward:

1) We temporarily disable the GitHub Issues and maintain the Google Code issues as the primary issue tracker.
2) We keep the GitHub account open. It has already been useful in encouraging contributions, and I would not want to lose that.
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.

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.

-Andrew

On May 28, 2014, at 2:29 PM, Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>> wrote:

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

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140528/fa20155e/attachment.html>