[MEI-L] Hosting MEI on GitHub

Wed May 28 23:48:45 CEST 2014

++ 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>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> 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>:
> >
> >>
> >> 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] 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] 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
> >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> >>>
> >>> _______________________________________________
> >>> mei-l mailing list
> >>> 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
> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> >
> > _______________________________________________
> > mei-l mailing list
> > 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
> 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/a54789ee/attachment.html>