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 later. 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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
