Move part of macports infrastructure to GitHub

[Ryan Schmidt]

On Mar 16, 2014, at 13:27, Ivan Larionov wrote:

> I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros:
> 
> * git >> svn

For you, moving from svn to git may be a pro; for me, it would initially be a con. I have a decade of experience with Subversion and a very good understanding of how it works and behaves, and only an extremely spotty understanding of git. It makes me uncomfortable every time I use it. That could be cured by spending some hours with a fine manual, but it would be something new to need to learn. Although I understand github does offer svn access to its git repositories, so it’s possible those like me who would prefer not to be forced to switch to git wouldn’t have to.

Note that Mac OS Forge already provides a read-only git mirror of the MacPorts Subversion repository:

http://www.macosforge.org/post/git-mirrors/

Perhaps that is already helpful to you.


> * pull requests are awesome! No need to poke around with patch files attached to tickets

I agree that in principle pull requests would seem like a better method than our current patches attached to tickets. In practice, I am still very unfamiliar and uncomfortable with the process.


> * nice UI, tools and infra around

I do like the github web interface. I like the github issue tracker better than Trac; it doesn’t distract with lots of fields. I like markdown better than Trac’s WikiFormatting. However, how would we convert the tens of thousands of existing issues, maintaining the formatting and Subversion revision number references? What about converting the Trac wiki to github wiki, and maintaining the wiki page references in the tickets? What about links to tickets, changesets, wiki pages that are found in years of our mailing list archives—can we successfully redirect those to their new home at github?

The options I see, none of which are happy, are:

* Move the code to github, but don’t move the issue tracker or wiki; keep those in Trac at Mac OS Forge. Keeping the old Subversion repository running read-only sowould let old Trac changeset links still work, but I’m not sure how we would link to github changesets. This would make the move to github much less useful I think.
* Move the code and also convert all the Trac content to github, and ultimately take down the Mac OS Forge Trac and svn servers. This would be a lot of work, I imagine.
* Move the code to github, keep Trac and svn running with the current content, and use github for new content (new issues, new wiki pages). This seems like a really bad idea as we would have to juggle two systems for years to come.


> which will result in more pros:
> 
> * people will look at macports more positively

That’s possible, but I think people should not view a project positively or negatively depending on its chosen hosting infrastructure (assuming that infrastructure works to the satisfaction of the project’s developers, which Mac OS Forge hosting infrastructure currently does for us). Instead they should judge a project on its usefulness.


> * and will contribute more!

We do already have lots of contributions. In fact we have more contributions than we can handle, as evidenced by all our open tickets. But it’s possible that by using git and therefore pull requests it might become easier to handle contributions and make us able to handle them quicker.


> Actually I see lot of people keeping their local ports at github: https://github.com/search?q=macports&type=Repositories&ref=searchresults

I suppose I have no objection to people doing that.


> What do you think?