I've come to really like the pull request workflow as well. Its a great way to code
reviews and github's UI/tools make it easy to review, comment on, and edit changes
before merging in a pull request.
On Feb 20, 2013, at 7:34 AM, Lukas Krejci <lkrejci(a)redhat.com> wrote:
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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel