On 06/03/12 20:20, Diederik van Liere wrote:
My concern is not about the UI of Gerrit, I know
it's popular within
WMF to say that it's UI sucks but I don't think that's the case and
even if it was an issue it's only minor. People have already suggested
that we might consider other code-review systems, I did a quick Google
search and we are the only community considering migrating from Gerrit
to Phabricator. I think this is besides the point: the real challenge
is moving to a gated-trunk model, regardless of the chosen code-review
tool. I cannot imagine other code-review tools that are also based on
a gated-trunk model and work with Git are much easier than Gerrit. The
complexity comes from the gated-trunk model, not from the tool.
Hmm. No. I understand that the UI when you have a change proposal, with
4 old alternatives, depending on several commits and other ones
depending on it will need to be more complex than subversion.
But when you look at a single diff it shouldn't be harder than our
well-known Code Review.
The gated-trunk model means that, when you clone or
pull from master,
it might be the case that files relevant to you have been changed but
that those new changes are waiting to be merged (the pull request
backlog, AKA the code-review backlog).
Maybe there should be a way to fetch all commits pending in gerrit and
show them to you inside git interface.
Suppose I clone master, but there are 10 commits
waiting to be
reviewed with files that are relevant to me. I am happily coding in my
own local branch and after a while ready to commit. Meanwhile, those
10 commits have been reviewed and merged and now when I want to merge
my branch back to master I get merge conflicts. Either I discover
these merge conflicts when my branch is merged back to master or if I
pull mid-way to update my local branch.
I'm more afraid that you commit and then we have 11 conflicting commits
waiting for review. And noone to even notice about that until two months
We will probably be in the situation where the same trivial fix is
independently submitted by several developers, though.
I wonder, does gerrit allow you to rebase a commit to an older version
from its interface? (I assume rebasing to a newer one is perfectly
supported, as it'd be a cherry-pick)
2) We need to come up with a smarter way determining
how to approach
the code-review backlog. Three overall strategies come to mind:
a) random, just pick a commit
b) time-based picking (either the oldest or the youngest commit)
c) 'impact' of commit
I don't think that's different than how we do it now. It's just that
reviewing becomes more important.