github migration

Lukas Krejci lkrejci at redhat.com
Wed Feb 20 12:34:40 UTC 2013


One more thing I wanted to make note of before we move to github are the 
possibilities it is going to give us with regards to the commit and code 
review process. Jirka and me had a very interesting discussion with members of 
the Katello team (github.com/katello) about their experience with the move 
(they migrated from fedorahosted to github circa 6 months ago) and I most of 
all wanted to share my impressions from that discussion with you.

They didn't do any upfront split of the code base because they saw no need for 
that at the time. When on github though, they decided that some new "outlying" 
parts of the code base would be developed in separate repos. They noted though 
that that only makes life slightly more difficult and would argue against heavy 
splitting of the repositories. They also noted that trying to use git modules 
to manage multiple repos is basically a recipe for disaster and we should 
avoid it if at all possible.

They migrated a single repository and gave every team member commit access to 
it, basically mirroring the approach they used for fedorahosted. Interestingly 
though they gravitated towards the pull request model of github because, as 
they said, it provides very good balance between a formal review requiring 
commit workflows required for example by gerrit and other tools and the more 
direct approach of commits straight into the repo. In github neither approach 
is enforced and in fact they mix them successfully. They commit 
"infrastructural" changes (like changes in the poms, etc) straight into the 
repository and use pull requests for code changes. They require a pull request 
to live for at least 24hrs (require is a strong word, they break that rule if 
necessary) so that enough people from different timezones have a chance to see 
it and generally require 2 other team members to give an "ack" on a pull 
request before it is merged into the main repository. Using pull requests is 
very straightforward for them as it can not only be done using github's web UI 
but the reviews can also be done through email and there also exists a 
commandline tool for working with them.

One thing to note about pull requests is that a merge of a pull request *is* 
an actual merge and as such can make a mess of the history. On the other hand, 
internally pull requests are just git branches and therefore can be easily 
rebased. The drawback of that approach is that it has to be done "manually", 
github's web UI can't do that. Katello use the former approach, having to live 
with more complex git history but with a clear indication that a pull request 
has been dealt with. On the other hand I think AS team use the latter 
approach. That keeps their mainline history relatively clean but they need to 
manually "close" a pull request and put a comment there saying that it has 
been merged. Github can't track that because the histories of the two branches 
remain separate after the rebase.

One more thing to note about the pull requests is that they don't require each 
developer to have a separate RHQ repo in their account. It is easily possible 
to create pull requests between branches in the same repository and therefore 
we can still adhere to the same model we used in fedorahosted - 1 repo with 
many feature and "individual" branches - and use pull requests between them 
and master in the same repo at will.

A great thing about github is that it has an extensive REST API that can be 
used for many many things including working with pull requests and therefore 
any kind of workflow can be scripted if we agree on using and adhering to it 
team-wide.

All in all, I think that while it is useful to have these discussions to be 
aware of the possibilities and challenges the move is going to bring to us, 
nothing prevents us from jumping fedorahosted right now. Versioning questions 
are mostly independent of the repo-split and the commit workflows github offers 
are flexible enough for us to change them as we go without much disruption.

The only thing I would wait for is the 4.6.0 release just so that we have a 
stable API version the plugins can be built against after they're split from 
the main repo (there have been (back compat) changes in the plugin API classes 
and therefore some current plugins need to be built against 4.6.0-SNAPSHOT 
plugin API).

Lukas

On Monday, February 11, 2013 11:01:40 John Sanda wrote:
> Where do we stand with respect to the github migration? What outstanding
> tasks are left before we can pull the trigger? Given that we have various
> RHQ and JON releases in flight, when is the best time to make the move?
> 
> - John
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list