Move part of macports infrastructure to GitHub

[Rainer Müller]

On 2014-03-16 19: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:

It is important to note that using git and GitHub are totally separate,
although many people fail to see that. Moving to git and moving to
GitHub are two separate issues for me, but they may have some overlaps.

Also note we had discussions on moving to a DVCS before. Some should
turn up with a search in the mail archive, although it may already have
been years ago we discussed this the last time.

> * git >> svn

I agree with that, as I am already using git for work and other
projects. However, I can only work with git now that I am proficient, I
had hated it for a long time before reaching that point. I am afraid of
the increased complexity of git and the changing workflow for other
developers.

We cannot simply swap out Subversion and bless a git mirror as the new
main ports tree, a new way of working with git has to be worked out first.

Coming from the Linux kernel, pure git expects a pull-based workflow.
One central instance pulls up changes from many other repositories into
the main repository. I would rule out such a person-based pull model for
MacPorts, as who would take the responsibility for all the merges?

At the moment, the MacPorts project gives out commit access to a central
repository. Transferring that to git, that would mean giving everyone
push access.

With the right infrastructure (such as gitolite [1]) that could work, as
it is required to limit the ability to overwrite work from others
(technically, pushing fast-forward changes only). For the developers,
this workflow requires a lot of rebase/merges locally and therefore a
high-level understanding of git.

Another option would be a machine-based pull model with reviews by
developers, such as the GitHub pull requests [2] or hosting an instance
of Gerrit [3] or Kiln [4].

These three review-based systems basically work in a way that a
developer pushes their changes and then (another) developer has to
acknowledge the changes in a web interface to be merged into the main
repository. It has the advantage that every commit gets a review by
someone else and also it removes the risk of someone pushing the wrong
change – such as accidentally rebasing a lot of commits or rewriting the
entire history, as that can happen with git, especially by unexperienced
users.

> * pull requests are awesome! No need to poke around with patch files
> attached to tickets
> * nice UI, tools and infra around

With this point you make the assumption we would use GitHub. How do you
imagine we would manage that as a separate infrastructure? How would we
hand out commit access and match mail forwards to GitHub usernames?

I don't even want to talk about the migration issues that would come up
when converting the Trac database to GitHub...

Also, as an ethical question, would it be right for MacPorts as a
non-profit project to promote GitHub as a profit-oriented company by
choosing it as the main hosting provider?

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

And for some others it will be more work to learn git only to get an
update to MacPorts...

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

Just in case you did not know that, you can already add any git ports
tree to your sources.conf and start using it. The official tree is the
only way to use ports and if someone wants to experiment with it you can
already create overlays that only contain new or updates to existing ports.

Rainer

[1] http://gitolite.com/gitolite/
[2] https://help.github.com/articles/using-pull-requests
[3] http://code.google.com/p/gerrit/
[4] http://www.fogcreek.com/kiln/