On Sun, Feb 12, 2012 at 15:49, Andrew Stormont <[email protected]> wrote: > Hi all, > > At the Illumos meetup in Brussels it was proposed that we migrate > illumos-userland to GitHub. There were several good reasons for making the > switch but the two main ones were: git is faster (because most of it is > written in C) and git is more popular (which hopefully means there are more > people familiar with it). > > I would like us to add this to the agenda for the next #oi-meeting and in > the mean time please feel free to reply with your thoughts/opinions about > switching to git. > > Thanks, > Andrew
I think this is a two part discussion: 1. Switching from Mercurial to Git. 2. Switching to a repository hosted on an external hosting site, with the features is provides. I am not going to go into the first part, since I am sure whichever tool we choose have the features we may need. If I had to vote for one of them, it would however be Git, since that's what I'm used to working with, and I don't really see any downsides to using Git. I would instead like to go further in depth on how the contribution process can open up to new developers, if/when we switch to an external code hosting site, and how the process of contributing changes may look. The following flowchart should show my idea for how contributions work: http://files.tenzer.dk/contribution-process.png (I am using GitHub as an example for the flowchart, that could be replaced with Bit Bucket or another site.) To quickly talk through it - new developers first of need to have a user on GitHub. That way they can create a fork of the illumos-userland repository on the site. They should create a new branch on their own fork for each change/package they want to add, since they then can put in a pull request to get the changes from one branch merged into the illumos-userland main repository. When a pull request gets in, it will trigger a build in Jenkins. Jenkins will then write a comment on the pull request with the results of the build. In case it failed, the contributor can work further on the code, and when new commits are added to the branch, it will start a new Jenkins build. When the build gets successful, the pull request will be tagged with "needs review", which then requires a moderator/trusted developer to look through the patch and accept it, or let the contributor know of any changes which may be required before we can accept it. For trusted developers, they can choose one of two things (this should probably be up for discussion). 1. Commit directly into the illumos-userland repository, the most direct way of putting stuff in. 2. Create the commits as they normally would, but instead of pushing them directly to illumos-userland, they make a pull request in order to get the commit checked by Jenkins. If the build is successful, we can make Jenkins accept the pull request by checking the user who made the pull request against the list of users with commit access to illumos-userland. Ideally everything should go through a pull request in order to get built by Jenkins so we make sure the code in illumos-userland can be build at all times. It only requires one extra step - to go and create a pull request, which basically just is a matter of clicking a button, and shortly describe what the pull request does. It is however up to the developers if they think this is reasonable or not. -- Venlig hilsen / Kind regards Jeppe Toustrup (aka. Tenzer) _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
