[oi-dev] Lets talk about Git

[Jeppe Toustrup]

On Sun, Feb 12, 2012 at 15:49, Andrew Stormont <andyjstormont at gmail.com> 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)