On Thursday, July 26, 2012, Faidon Liambotis wrote:
This is not to you specifically but as a general remark: there are multiple other alternatives that have been mentioned besides Gerrit and GitHub with a potential of getting the best of both worlds. I think it's better to not polarize the discussion between the two most popular options at this point and talk about all options.
Nice segue into a topic that I've been meaning to get to. :) Right now, the serious alternatives seem to be: * Sticking with Gerrit (with GitHub integration) * Moving fully to GitHub * Moving to Phabricator (though the proposal is pretty thin right now)
Nothing else has been advocated with a degree of seriousness as to warrant consideration at this point. That's not to say we're done with those options; if someone wants to put together a serious proposal, there's still a little time. However, in order to practically consider the alternatives, we need to have the serious proposals enumerated, and a credible plan for addressing any deficiencies.
I've gone through and modified the criteria, splitting up the MUSTs from the SHOULDs: http://www.mediawiki.org/wiki/Git/Gerrit_evaluation
Even the "sticking with Gerrit" section is currently thin on credibly meeting the criteria, so we'll have to beef up our stated plan for getting it up-to-snuff.
Here's the timeline I'd like to propose: * July 30, noon PDT - reasonably complete draft sections need to be in place * August 1, 9am PDT - complete proposals due
A few of us are planning to meet Monday afternoon to figure out exactly what the rest of the process looks like, so that first deadline is going to be very important for understanding how many options we're truly considering.
Thanks Rob
On Thu, Jul 26, 2012 at 11:27:44AM -0700, Rob Lanphier wrote:
Nothing else has been advocated with a degree of seriousness as to warrant consideration at this point. That's not to say we're done with those options; if someone wants to put together a serious proposal, there's still a little time. However, in order to practically consider the alternatives, we need to have the serious proposals enumerated, and a credible plan for addressing any deficiencies.
I don't understand. I thought we were collecting problems and *ideas* on how to solve them, not solid plans for a migration.
You're basically comparing two options that have little or no work involved (not changing Gerrit, moving to an externally-maintained service that most of us know how it works) vs. plans that need *time* to install, play with and evaluate.
Has anyone been allocated to that task? I don't like either of the two options but don't think I can just stop what I'm doing and spend a week evaluating e.g. Gitlab, Barkeep and Phabricator just to present my argument (or counterargument) to the Wiki page.
My understanding of the process was that we would collect a broad set of arguments/ideas/proposals and people would be later assigned to the task of evaluating them and proposing a viable solution and a migration path (or not, and propose that we stay with Gerrit).
The wiki page seems to also imply something like that by saying: Brion Vibber will lead this evaluation, with help from Chad Horohoe and David Schoonover.
If it's me that misunderstood that's fine and I'm sorry. I'll just feel a bit silly for trying to argue for an impossible outcome :)
Regards, Faidon
Rob Lanphier wrote:
A few of us are planning to meet Monday afternoon to figure out exactly what the rest of the process looks like, so that first deadline is going to be very important for understanding how many options we're truly considering.
Well, at least you're being open about not being open.
It's somewhat ironic that you have a group of people who regularly champion the virtues of open source software ("you can hack the code!") who have picked a software solution that's (apparently) nearly impossible to modify. Even eliminating Gerrit's vomit color scheme would be a vast improvement, but as I understand it, even basic CSS changes are a no-go with Gerrit.
A few people on this list have gone so far as to say "but the next release is always better!" I realize I was being a bit tongue-in-cheek by suggesting earlier that Gerrit's UI was developed by Microsoft, but to have developers now spouting corporate justifications for shitty software? I'm left to wonder what the hell happened.
I'm lost as to how Gerrit was ever considered an option previously and how it's still an option on the table today, given its apparent inflexibility. Say what you will about MediaWiki's CodeReview extension, but on its worst day, it never garnered as much resentment as Gerrit.
MZMcBride
On Thu, Jul 26, 2012 at 10:04 PM, MZMcBride z@mzmcbride.com wrote:
Rob Lanphier wrote: It's somewhat ironic that you have a group of people who regularly champion the virtues of open source software ("you can hack the code!") who have picked a software solution that's (apparently) nearly impossible to modify. Even eliminating Gerrit's vomit color scheme would be a vast improvement, but as I understand it, even basic CSS changes are a no-go with Gerrit.
Can you please stop saying things about Gerrit that are just patently untrue? I've taken many times to explain why these statements aren't true.
Gerrit's source is not impregnable, I've found it very easy to begin contributing upstream. Not to mention, most people don't bother to contribute upstream anyway.
CSS is customizable and it's customizable now. Nobody's bothered to do so, however. I welcome suggestions, but nobody's said anything to me about things they'd like done.
-Chad
On Thu, Jul 26, 2012 at 12:49 PM, Faidon Liambotis faidon@wikimedia.orgwrote:
My understanding of the process was that we would collect a broad set of arguments/ideas/proposals and people would be later assigned to the task of evaluating them and proposing a viable solution and a migration path (or not, and propose that we stay with Gerrit).
Hi Faidon,
Yes, we're seeking a broad range of proposals. However, "proposals" is the key word. That means looking the requirements, reading the website and matching against those requirements, and stitching together something that at least looks good on paper. I'm not expecting anyone to set up a prototype, but I am asking that, given how long we've been talking about this, that we narrow down our options a bit to the things that we know are worth looking at rather than (still, a year later) having the "have you looked at this?" discussion again.
As far as "people being assigned to the the task of evaluating them", I think you may be overestimating the number of people we have floating around to do this work. "People" is basically Chad, who is pretty burnt out on working on this, and is exasperated with this process, but without drafting someone outside my group (like you?) :), I don't have many options. Having Chad do this means taking one of our most experienced MediaWiki developers, and having him not work on MediaWiki, but instead, do more evaluation of code review tools.
Before doing that to Chad, I'm asking people who believe passionately that we need to move off Gerrit to actually tell us what they'd like to move to in a structured, constructive way. I don't think that's too much to ask.
Rob
On Fri, Jul 27, 2012 at 2:36 AM, Rob Lanphier robla@wikimedia.org wrote:
As far as "people being assigned to the the task of evaluating them", I think you may be overestimating the number of people we have floating around to do this work. "People" is basically Chad, who is pretty burnt out on working on this, and is exasperated with this process, but without drafting someone outside my group (like you?) :), I don't have many options. Having Chad do this means taking one of our most experienced MediaWiki developers, and having him not work on MediaWiki, but instead, do more evaluation of code review tools.
Before doing that to Chad, I'm asking people who believe passionately that we need to move off Gerrit to actually tell us what they'd like to move to in a structured, constructive way. I don't think that's too much to ask.
I'd like to just clarify Rob's comments here, since they're about me :)
When Rob says "burnt out," I really am tired. This process has been very draining, but necessary. It's very important that we get this right, which is why I've been committed since day 1 to helping absolutely everyone with absolutely everything relating to Git. Got a question? Ask me. Need a new repo? Ask me. But being a one-man-army tires you after awhile and that's where I'm at right now. But like I said, I'm committed to seeing this through and making sure we're in the best possible position going forward.
I feel like "exasperated" has a bit of a negative connotation to it. Better way to describe it would be "would very much like for this to find resolution so I can fade back into obscurity and work on cool things again, like Config overhaul which I really really want to see done so much." :)
Again, I'm here to support the community on this. Whatever the end result is, I'll be behind it.
-Chad
On Thu, Jul 26, 2012 at 11:36:50PM -0700, Rob Lanphier wrote:
On Thu, Jul 26, 2012 at 12:49 PM, Faidon Liambotis faidon@wikimedia.orgwrote:
My understanding of the process was that we would collect a broad set of arguments/ideas/proposals and people would be later assigned to the task of evaluating them and proposing a viable solution and a migration path (or not, and propose that we stay with Gerrit).
Yes, we're seeking a broad range of proposals. However, "proposals" is the key word. That means looking the requirements, reading the website and matching against those requirements, and stitching together something that at least looks good on paper. I'm not expecting anyone to set up a prototype, but I am asking that, given how long we've been talking about this, that we narrow down our options a bit to the things that we know are worth looking at rather than (still, a year later) having the "have you looked at this?" discussion again.
I think GitLab looks promising but I'm unable to judge it against all of our requirements just from the online demo and without spending some amount of time on it. I just put some pros and cons as I see them to the Wiki page and hope it can be considered.
Regards, Faidon
On Jul 27, 2012 7:17 AM, "Faidon Liambotis" faidon@wikimedia.org wrote:
I think GitLab looks promising but I'm unable to judge it against all of our requirements just from the online demo and without spending some amount of time on it. I just put some pros and cons as I see them to the Wiki page and hope it can be considered.
I would also like Gitlabs to be considered, so I'll poke at that wiki page later. I may or may not have time to play with it before Monday.
Roan
On Thu, Jul 26, 2012 at 7:04 PM, MZMcBride z@mzmcbride.com wrote:
Rob Lanphier wrote:
A few of us are planning to meet Monday afternoon to figure out exactly what the rest of the process looks like, so that first deadline is going to be very important for understanding how many options we're truly considering.
Well, at least you're being open about not being open.
Well, it's very likely the staff that will end up doing the work. Also, we're meeting to figure out the rest of the process. We're not making a decision. So far the entire process has been in the open, and will continue to be so. Good to see you're assuming good faith, though ;).
You've already admitted that you don't use Gerrit, so do you have a really large stake in this?
It's somewhat ironic that you have a group of people who regularly champion the virtues of open source software ("you can hack the code!") who have picked a software solution that's (apparently) nearly impossible to modify. Even eliminating Gerrit's vomit color scheme would be a vast improvement, but as I understand it, even basic CSS changes are a no-go with Gerrit.
A few people on this list have gone so far as to say "but the next release is always better!" I realize I was being a bit tongue-in-cheek by suggesting earlier that Gerrit's UI was developed by Microsoft, but to have developers now spouting corporate justifications for shitty software? I'm left to wonder what the hell happened.
Every release *has* been much better and the releases are often, and that's a great thing. It's not a corporate justification, it's reality. Having a really responsive and active upstream is awesome.
We have other pieces of infrastructure that are similar. Take bugzilla for instance. We don't really modify it much, we don't think its interface is great, but we're thankful when upstream changes help us. Also, there's no really great alternative to bugzilla. We've had numerous discussions about replacing bugzilla, and the discussion always dies out because the alternatives are just as bad or worse. We use what works and generally only change things when there's a really strong justification for doing so.
I'm lost as to how Gerrit was ever considered an option previously and how it's still an option on the table today, given its apparent inflexibility. Say what you will about MediaWiki's CodeReview extension, but on its worst day, it never garnered as much resentment as Gerrit.
It was considered because it worked and it was better than any alternatives we found. It was easy to integrate into our toolsets with minimal effort. Other solutions would have required extensive code changes which we honestly don't have time to make.
I know people complain about Gerrit a lot, but I personally find it much better than our previous toolset. We couldn't have reasonably opened our ops infrastructure without some form of pre-merge review. Also, we can much more easily give people accounts. In our previous workflow SVN access required developers to have prior code examples, and we have to approve them to ensure they wouldn't submit insecure code. We can just give people accounts now, and we eventually allow people to self-register as well. In fact, this is one of my top goals after upgrading openstack and adding a new Labs zone in eqiad.
- Ryan
Ryan Lane wrote:
You've already admitted that you don't use Gerrit, so do you have a really large stake in this?
Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most people, I think I would use Gerrit more if it weren't so awful. Just tonight I was trying to get an index of Gerrit contributors (owners, I guess the term is). Something similar to this list from the SVN system: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author. Apparently Gerrit doesn't have a feature to list authors like this. All I wanted to do was find a particular user and look at his contributions. And, as usual, it took twenty minutes instead of ten seconds because Gerrit sucks.
How does anyone use Gerrit?
Every release *has* been much better and the releases are often, and that's a great thing. It's not a corporate justification, it's reality. Having a really responsive and active upstream is awesome.
You'll have to forgive me, but the only way I can read this is, "the car now breaks down two minutes into the journey; it used to break down a minute in!"
I know people complain about Gerrit a lot, but I personally find it much better than our previous toolset.
I think a lot of people are frustrated by the fact that the types of problems being encountered in Gerrit would typically be trivial to fix (CSS precedence, for example). The fact that they're not runs against a lot of core Wikimedia principles.
We can just give people accounts now, and we eventually allow people to self-register as well. In fact, this is one of my top goals after upgrading openstack and adding a new Labs zone in eqiad.
Yes, self-registration would be fantastic. :-) I commented on this bug last Saturday: https://bugzilla.wikimedia.org/show_bug.cgi?id=37628 ("Creating a Git/Gerrit/Labs account requires human intervention"). I realize that you and the other ops folks are busy, but if someone could at least explain the current process, it would give volunteer developers a fighting chance of helping out. Not having the faintest idea how the current account creation process works, I can't help or find anyone to help make it better.
MZMcBride
On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride z@mzmcbride.com wrote:
Ryan Lane wrote:
You've already admitted that you don't use Gerrit, so do you have a really large stake in this?
Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most people, I think I would use Gerrit more if it weren't so awful. Just tonight I was trying to get an index of Gerrit contributors (owners, I guess the term is). Something similar to this list from the SVN system: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author. Apparently Gerrit doesn't have a feature to list authors like this. All I wanted to do was find a particular user and look at his contributions. And, as usual, it took twenty minutes instead of ten seconds because Gerrit sucks.
So, you found something you'd like added to the software: a user list. Have you entered a bug? The problem you are encountering is that you are used to a piece of software, and the new software doesn't have the exact same feature set. This happens, and will happen with any new tool if we switch, too.
There's an open bug for this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=35508
Note that the bug mentions a number of ways you can get a user list outside of Gerrit. I think it would be nice to have Gerrit itself have the user list interface. With extension support in Gerrit 2.5, we may be able to implement it ourselves.
How does anyone use Gerrit?
I use it successfully every single day. I review code, I add changes, I get statistics on repos. It works well for me. Guess what? I find the old code review system to be just as hard to use as Gerrit. Know why? I didn't use the old code review system much.
Every release *has* been much better and the releases are often, and that's a great thing. It's not a corporate justification, it's reality. Having a really responsive and active upstream is awesome.
You'll have to forgive me, but the only way I can read this is, "the car now breaks down two minutes into the journey; it used to break down a minute in!"
This is a fallacious argument. For most use cases Gerrit works perfectly well. The fixes coming in each release are easing some of the use cases that don't work so well.
Maybe as a non-developer Gerrit doesn't do what you want. As a developer it does most of what I want. It doesn't do some things I want, though. I want free-form tagging, for instance, which is on the roadmap for a future release (and Chad has already started adding in code that is required for this feature).
I know people complain about Gerrit a lot, but I personally find it much better than our previous toolset.
I think a lot of people are frustrated by the fact that the types of problems being encountered in Gerrit would typically be trivial to fix (CSS precedence, for example). The fact that they're not runs against a lot of core Wikimedia principles.
As mentioned at least twice already in these threads, this is simply not true. It's possible to fix the CSS right now (and if you look at OpenStack's Gerrit, you'd notice they've already done so).
We can just give people accounts now, and we eventually allow people to self-register as well. In fact, this is one of my top goals after upgrading openstack and adding a new Labs zone in eqiad.
Yes, self-registration would be fantastic. :-) I commented on this bug last Saturday: https://bugzilla.wikimedia.org/show_bug.cgi?id=37628 ("Creating a Git/Gerrit/Labs account requires human intervention"). I realize that you and the other ops folks are busy, but if someone could at least explain the current process, it would give volunteer developers a fighting chance of helping out. Not having the faintest idea how the current account creation process works, I can't help or find anyone to help make it better.
I could have sworn there was another bug open for this that documented what needed to get done. I just spent a few minutes updating the bug. It's likely a fairly small OpenStackManager change, and a labsconsole configuration change. As mentioned it's on my list after Labs upgrades. If someone else wants to tackle it first, I'd love that.
- Ryan
On Thu, 26 Jul 2012 23:43:51 -0700, Ryan Lane rlane32@gmail.com wrote:
On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride z@mzmcbride.com wrote:
Ryan Lane wrote:
You've already admitted that you don't use Gerrit, so do you have a really large stake in this?
Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most people, I think I would use Gerrit more if it weren't so awful. Just tonight I was trying to get an index of Gerrit contributors (owners, I guess the term is). Something similar to this list from the SVN system: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author. Apparently Gerrit doesn't have a feature to list authors like this. All I wanted to do was find a particular user and look at his contributions. And, as usual, it took twenty minutes instead of ten seconds because Gerrit sucks.
So, you found something you'd like added to the software: a user list. Have you entered a bug? The problem you are encountering is that you are used to a piece of software, and the new software doesn't have the exact same feature set. This happens, and will happen with any new tool if we switch, too.
There's an open bug for this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=35508
Note that the bug mentions a number of ways you can get a user list outside of Gerrit. I think it would be nice to have Gerrit itself have the user list interface. With extension support in Gerrit 2.5, we may be able to implement it ourselves.
How does anyone use Gerrit?
I use it successfully every single day. I review code, I add changes, I get statistics on repos. It works well for me. Guess what? I find the old code review system to be just as hard to use as Gerrit. Know why? I didn't use the old code review system much.
Every release *has* been much better and the releases are often, and that's a great thing. It's not a corporate justification, it's reality. Having a really responsive and active upstream is awesome.
You'll have to forgive me, but the only way I can read this is, "the car now breaks down two minutes into the journey; it used to break down a minute in!"
This is a fallacious argument. For most use cases Gerrit works perfectly well. The fixes coming in each release are easing some of the use cases that don't work so well.
Maybe as a non-developer Gerrit doesn't do what you want. As a developer it does most of what I want. It doesn't do some things I want, though. I want free-form tagging, for instance, which is on the roadmap for a future release (and Chad has already started adding in code that is required for this feature).
I want whatever review system we use to support real review branches; - Review sets are heads with multiple commits, not single commits. - We don't amend commits, we make new ones to the head of the review branch. - -no-ff merge commits are used so that only the final commit code makes it directly into master.
Scrap all the other complaints. This pattern of amending commits is by far the worst thing about our current workflow. Development history and minor contributions that never make it into the repo. "Committer" going to the person who fixes a typo rather than the person who writes the code. Confusion over whether someone has rebased or let unrelated changes leak into their patchset. Huge development effort by multiple people potentially turning into a single commit with a single committer. ...
At this point I think the real question we have is this: "Can we reasonably get Gerrit to support real review branches?"
If that answer to that question is no. Or "not without very significant development". Then the only option we have is to track down the system that we can get to support that with the most reasonable amount of development effort.
I know people complain about Gerrit a lot, but I personally find it much better than our previous toolset.
I think a lot of people are frustrated by the fact that the types of problems being encountered in Gerrit would typically be trivial to fix (CSS precedence, for example). The fact that they're not runs against a lot of core Wikimedia principles.
As mentioned at least twice already in these threads, this is simply not true. It's possible to fix the CSS right now (and if you look at OpenStack's Gerrit, you'd notice they've already done so).
We can just give people accounts now, and we eventually allow people to self-register as well. In fact, this is one of my top goals after upgrading openstack and adding a new Labs zone in eqiad.
Yes, self-registration would be fantastic. :-) I commented on this bug last Saturday: https://bugzilla.wikimedia.org/show_bug.cgi?id=37628 ("Creating a Git/Gerrit/Labs account requires human intervention"). I realize that you and the other ops folks are busy, but if someone could at least explain the current process, it would give volunteer developers a fighting chance of helping out. Not having the faintest idea how the current account creation process works, I can't help or find anyone to help make it better.
I could have sworn there was another bug open for this that documented what needed to get done. I just spent a few minutes updating the bug. It's likely a fairly small OpenStackManager change, and a labsconsole configuration change. As mentioned it's on my list after Labs upgrades. If someone else wants to tackle it first, I'd love that.
- Ryan
Daniel Friesen write:
I want whatever review system we use to support real review branches;
- Review sets are heads with multiple commits, not single commits.
- -no-ff merge commits are used so that only the final commit code makes
it directly into master.
We have disallowed branch creation and merging for now, that can definitely be opened up. Chad recently opened the sandbox reference and we have a few of them:
remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks
They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox
- We don't amend commits, we make new ones to the head of the review
branch.
You will be able to do that. I am afraid the end result is not going to look nice history wise with ton of followups to fix previous commits. That will definitely make finding the root cause of bug and its context harder to find out. Think about a commit that introduce a bug for which the commit message is:
Ahh typo in 3124a09 fix it
It is not going to be helpful :-D
Scrap all the other complaints. This pattern of amending commits is by far the worst thing about our current workflow.
I firmly disagree with you there. It let someone send some code then enhance it without cluttering everyone else code. That let you work in a collaborative way, finding out what the other person has done patch after patch. We eventually end up with a patchset that only got published (merged) to everyone whenever it is close to perfect. That makes our code history nicer and push the review stress to the submitters (lot of people) instead of toward the reviewers (few people).
I do agree though that the system can be confusing and is poorly toolized. git-review is a step to abstract the whole patchset system, but I am sure we can make it a better/easier tool to use.
Development history and minor contributions that never make it into the repo.
I think we do not care about the history of a change. The typo / comment update / logic errors, I am sure we do not care about. If someone has a change that requires to be split in several changes, that should easier be a branch (see sandbox above) or a chain of changes made interdependants (which is really just a local branch).
How would you do that? Well lets say I want to update our documentation to several area. I would first create a local branch:
git checkout -b doc -t origin/master <do my doc updates, commit as needed>
I then push that local branch to Gerrit (git push doc:refs/for/master), that craft a change per commit. Whenever one of the commit need to be amended I edit my local branch commits with git rebase --interactive. Once happy I repush the whole branch and Gerrit magically update all the patchsets.
The drawback is that editing just a commit out of several one will still trigger a new patchset to all the child commits although there is no code change per see (the parent got changed). That could be detected in Gerrit I guess. We might have Gerrit to automatically rebase children whenever a parent is modified. Gerrit could also use a feature to prevent the chain of commits to be submitted until they have all been reviewed. Once the last change is submitted, that will trigger a git merge --no-ff. We currently have to handle that manually by submitting the first commit last.
"Committer" going to the person who fixes a typo rather than the person who writes the code.
The Author field is kept around (unless someone amend it). See as an example https://gerrit.wikimedia.org/r/#/c/5550/, I am the patch author, Saper sent patchset 3 but I am still mentioned as the author.
git does not support multiple authors as far as I know, but one could add himself in the commit message by adding a new field such as:
Co-authored-by: John Doh johndoe@example.org
Confusion over whether someone has rebased or let unrelated changes leak into their patchset.
That is more a matter of educating our developers. Whenever I submit a new patchset, I add a cover message in Gerrit to introduce what that change did even if it is "just a rebase".
Huge development effort by multiple people potentially turning into a single commit with a single committer. ...
As I said previously, huge effort involving multiple persons could be made branch.
At this point I think the real question we have is this: "Can we reasonably get Gerrit to support real review branches?"
The answer is most definitely yes. We would need to open up branches creations to everyone.
If that answer to that question is no. Or "not without very significant development". Then the only option we have is to track down the system that we can get to support that with the most reasonable amount of development effort.
I tend to agree on that :-)
On Fri, 27 Jul 2012 01:10:52 -0700, Antoine Musso hashar+wmf@free.fr wrote:
Daniel Friesen write:
I want whatever review system we use to support real review branches;
- Review sets are heads with multiple commits, not single commits.
- -no-ff merge commits are used so that only the final commit code makes
it directly into master.
We have disallowed branch creation and merging for now, that can definitely be opened up. Chad recently opened the sandbox reference and we have a few of them:
remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks
They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox
- We don't amend commits, we make new ones to the head of the review
branch.
You will be able to do that. I am afraid the end result is not going to look nice history wise with ton of followups to fix previous commits. That will definitely make finding the root cause of bug and its context harder to find out. Think about a commit that introduce a bug for which the commit message is:
Ahh typo in 3124a09 fix it
It is not going to be helpful :-D
Scrap all the other complaints. This pattern of amending commits is by far the worst thing about our current workflow.
I firmly disagree with you there. It let someone send some code then enhance it without cluttering everyone else code. That let you work in a collaborative way, finding out what the other person has done patch after patch. We eventually end up with a patchset that only got published (merged) to everyone whenever it is close to perfect. That makes our code history nicer and push the review stress to the submitters (lot of people) instead of toward the reviewers (few people).
I do agree though that the system can be confusing and is poorly toolized. git-review is a step to abstract the whole patchset system, but I am sure we can make it a better/easier tool to use.
Development history and minor contributions that never make it into the repo.
I think we do not care about the history of a change. The typo / comment update / logic errors, I am sure we do not care about. If someone has a change that requires to be split in several changes, that should easier be a branch (see sandbox above) or a chain of changes made interdependants (which is really just a local branch).
How would you do that? Well lets say I want to update our documentation to several area. I would first create a local branch:
git checkout -b doc -t origin/master <do my doc updates, commit as needed>
I then push that local branch to Gerrit (git push doc:refs/for/master), that craft a change per commit. Whenever one of the commit need to be amended I edit my local branch commits with git rebase --interactive. Once happy I repush the whole branch and Gerrit magically update all the patchsets.
The drawback is that editing just a commit out of several one will still trigger a new patchset to all the child commits although there is no code change per see (the parent got changed). That could be detected in Gerrit I guess. We might have Gerrit to automatically rebase children whenever a parent is modified. Gerrit could also use a feature to prevent the chain of commits to be submitted until they have all been reviewed. Once the last change is submitted, that will trigger a git merge --no-ff. We currently have to handle that manually by submitting the first commit last.
"Committer" going to the person who fixes a typo rather than the person who writes the code.
The Author field is kept around (unless someone amend it). See as an example https://gerrit.wikimedia.org/r/#/c/5550/, I am the patch author, Saper sent patchset 3 but I am still mentioned as the author.
git does not support multiple authors as far as I know, but one could add himself in the commit message by adding a new field such as:
Co-authored-by: John Doh johndoe@example.org
Confusion over whether someone has rebased or let unrelated changes leak into their patchset.
That is more a matter of educating our developers. Whenever I submit a new patchset, I add a cover message in Gerrit to introduce what that change did even if it is "just a rebase".
Huge development effort by multiple people potentially turning into a single commit with a single committer. ...
As I said previously, huge effort involving multiple persons could be made branch.
At this point I think the real question we have is this: "Can we reasonably get Gerrit to support real review branches?"
The answer is most definitely yes. We would need to open up branches creations to everyone.
If that answer to that question is no. Or "not without very significant development". Then the only option we have is to track down the system that we can get to support that with the most reasonable amount of development effort.
I tend to agree on that :-)
Most of your reply appears to be based on an assumption based around real branches in Gerrit rather than the ephemeral-branch-as-review/commit-as-patchset pattern discussed in the list earlier. Naturally the way you're suggesting to configure Gerrit is not the way I'm suggesting it work.
Review pages for what we see now as individual commits would be an ephemeral branch. Really just a moving head. When it gets accepted there wouldn't really be any head left in refs/heads/ as a branch. On the review pages the spot were we see "patchsets" be individual commits in that faux branch. Instead of being completely separate commits these would be actual commits building on each other.
Though rather than taking that Gerrit oriented description. Why not just read the previous emails. This one is my explanation of a --no-ff workflow: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/62461/... Shortly after I posted that description Platonides independently ended up describing basically the same thing I was suggesting: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/62461/...
You also seem to be making a false assumption about history based around limitations in linear history like in svn that don't exist in a non-linear --no-ff merge commit environment.
When you merge sets of changes into the master using --no-ff (Gerrit, whatever would do this automatically) the individual commits never really become part of master. They are there, they are in the history. But they are on a side of the branch you don't use unless you really mean to. When you are walking through the history of master (bisecting) you only want to walk one side of master. There is no point in splitting in two there as the commits that never got directly committed into master can never be the source of a bug. Because these sides are separate commits like "Ahh typo in 3124a09 fix it" will NEVER get in the way of fixing something. In fact, once you do find the commit that introduced a bug you can go into the other side of the branch and drill down into the individual commits and discover whether this bug introduced was something fundamental to the addition to core or was a last minute mistake caused after someone told the committer to fix something else and ended up creating a bug while fixing one.
On Jul 27, 2012 1:11 AM, "Antoine Musso" > We have disallowed branch creation and merging for now, that can
definitely be opened up. Chad recently opened the sandbox reference and we have a few of them:
remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks
They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox
This is a great feature, but I think most people realize it exists. Was it ever publicized widely?
Roan
On Fri, Jul 27, 2012 at 11:33 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Jul 27, 2012 1:11 AM, "Antoine Musso" > We have disallowed branch creation and merging for now, that can
definitely be opened up. Chad recently opened the sandbox reference and we have a few of them:
remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks
They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox
This is a great feature, but I think most people realize it exists. Was it ever publicized widely?
I sent out an e-mail announcing it: "Personal sandbox space in Gerrit" [0]
It was also documented on-wiki: https://www.mediawiki.org/wiki/Gerrit/personal_sandbox
-Chad
[0] http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/061584.html
Le 27/07/12 04:04, MZMcBride wrote: <snip
It's somewhat ironic that you have a group of people who regularly champion the virtues of open source software ("you can hack the code!") who have picked a software solution that's (apparently) nearly impossible to modify. Even eliminating Gerrit's vomit color scheme would be a vast improvement, but as I understand it, even basic CSS changes are a no-go with Gerrit.
You can change the CSS, even the head/footer html:
http://gerrit-documentation.googlecode.com/svn/Documentation/2.4.2/config-he...
Openstack has a different style: https://review.openstack.org/
Roan did a skin that even ship jQuery: https://gerrit.wikimedia.org/r/#/c/3285/
So that is definitely doable. It is currently blocked because the build-in CSS are loaded AFTER the user CSS which is totally dumb but is definitely an easy fix.
A few people on this list have gone so far as to say "but the next release is always better!" I realize I was being a bit tongue-in-cheek by suggesting earlier that Gerrit's UI was developed by Microsoft, but to have developers now spouting corporate justifications for shitty software? I'm left to wonder what the hell happened.
It goes better after each releases and they upstream release often. That is definitely better than a company throwing a bone at the community from time to time or not willing to merge community patches.
The UI could probably have used a designer. As for the Microsoft, I remember from the 90's some design guidance for third parties such as how to position buttons, the margin to let around them and so on. I urge you to have a look at the Windows Phone 7 GUI which is definitely nicer, cleaner and easier to use than the Android/iPhone interfaces. http://www.microsoft.com/windowsphone/
I'm lost as to how Gerrit was ever considered an option previously and how it's still an option on the table today, given its apparent inflexibility.
I did mention how Android used a homemade tool to do the reviews. It was introduced to me by a friend who is doing Android development for mobile phone companies. At first I was like: what about the existing google code or github? Then he explained me their pre commit workflow and it made me sure we wanted to use that. I think Ryan met the OpenStack folks who are using Gerrit. That probably convinced him it was the right tool for us too.
Say what you will about MediaWiki's CodeReview extension, but on its worst day, it never garnered as much resentment as Gerrit.
Our CodeReview tool lacked a good set of features such as the inline commenting (which I coded but was reverted when 1.19 came live). It made it very difficult to keep track of the follow up and comment reply. Overall I am not regretting our old tool and will never come back to it.
MZ, Do you even have a labs account? Your continuous rants are far from being constructive and makes everyone lose their time.
On Fri, Jul 27, 2012 at 3:46 AM, Antoine Musso hashar+wmf@free.fr wrote:
So that is definitely doable. It is currently blocked because the build-in CSS are loaded AFTER the user CSS which is totally dumb but is definitely an easy fix.
It's not quite as easy as I had hoped, unfortunately. However, it can be worked around (slap !important on everything), and I am still very actively researching a fix for it. In fact, I spent the vast majority of this week playing with upstream. Other than researching that bug, a couple of other cool things I worked on were:
1) I reviewed some improvements made by another developer to the plugin interface that will make it into 2.5. 2) I wrote my own plugin (in less than an hour and less than 100 LOC) to solve a silly issue I've hit. 3) I contributed a lot of fixes to the "delete-project" plugin (which we need, badly), and as a result it's now working and will be coming out along with 2.5. 4) I also spent quite a bit of time diagnosing some of the "diff bugs" that people have been hitting in Webkit-based browsers. I didn't get a fix, but I did find out a lot and reported all that information upstream.
Also, if anyone tells me that upstream is not active enough, I ask you to please look at a commit I made 2 days ago[0]. I know it wasn't earth- shattering, or even really important. What was important, is that it was reviewed and merged in *less than a minute* without any action on my part. All upstream contributions receive quite a bit of feedback, and things get merged into master every single day. I talk with the Gerrit guys constantly, and they've been nothing but supportive and helpful in both my questions and helping to resolve our issues.
-Chad
Antoine Musso wrote:
MZ, Do you even have a labs account? Your continuous rants are far from being constructive and makes everyone lose their time.
Nope. I looked at getting one once or twice, but the process seemed too bureaucratic and I ended up walking away. I imagine I'll make one once self-registration becomes possible.
I don't think it's fair to say that my posts have been unconstructive. I've tried to present actual problems (such as the lack of an authors list) that inhibit being able to effectively use Gerrit. I've also documented my experiences with Gerrit's UI, which to me is completely unintuitive (for example, finding the code inspection links beneath "tree" or "gitweb" took me weeks). In May, I tried to create a page about Gerrit's problems: https://www.mediawiki.org/wiki/Gerrit/Problems. I don't know Java or Prolog, otherwise I might have offered to help improve Gerrit directly.
Instead, all I can do is share my experiences with the tool in a conversation about it and alternatives. You sound frustrated in your post, hashar, but I don't think you're frustrated with me. If I had to use Gerrit every day (in its current form), I'd be frustrated as well. Though in its defense, once you learn where the secret links and menus and buttons are, most of the needed functionality is there.
Ryan Lane wrote:
So, you found something you'd like added to the software: a user list. Have you entered a bug? The problem you are encountering is that you are used to a piece of software, and the new software doesn't have the exact same feature set. This happens, and will happen with any new tool if we switch, too.
There's an open bug for this:
Thank you for the bug link.
Note that the bug mentions a number of ways you can get a user list outside of Gerrit. I think it would be nice to have Gerrit itself have the user list interface. With extension support in Gerrit 2.5, we may be able to implement it ourselves.
It feels a bit like buying a car that has no steering wheel. I didn't really want to overrun our bug tracker with Gerrit bugs, but I can certainly file a few against it.
I'm not trying to be an asshole, but I really don't understand how such a basic feature is missing (which is what I meant by "how does anyone use Gerrit?"). There's a dashboard feature that accepts user IDs to view a particular user's contributions to Gerrit, but without an index (or some other way to match IDs to usernames), I really have no idea how you're supposed to be able to look at a particular user's contributions.
I think a lot of people are frustrated by the fact that the types of problems being encountered in Gerrit would typically be trivial to fix (CSS precedence, for example). The fact that they're not runs against a lot of core Wikimedia principles.
As mentioned at least twice already in these threads, this is simply not true. It's possible to fix the CSS right now (and if you look at OpenStack's Gerrit, you'd notice they've already done so).
I know about OpenStack's CSS customizations. With regard to Wikimedia's Gerrit installation and CSS, I'll believe it when I see it. :-)
Yes, self-registration would be fantastic. :-) I commented on this bug last Saturday: https://bugzilla.wikimedia.org/show_bug.cgi?id=37628 ("Creating a Git/Gerrit/Labs account requires human intervention"). I realize that you and the other ops folks are busy, but if someone could at least explain the current process, it would give volunteer developers a fighting chance of helping out. Not having the faintest idea how the current account creation process works, I can't help or find anyone to help make it better.
I could have sworn there was another bug open for this that documented what needed to get done. I just spent a few minutes updating the bug. It's likely a fairly small OpenStackManager change, and a labsconsole configuration change. As mentioned it's on my list after Labs upgrades. If someone else wants to tackle it first, I'd love that.
Great, thank you for updating the bug.
And thank you both for your thoughtful replies. I appreciate them. :-)
For what it's worth, I think Ryan makes a compelling case for sticking with Gerrit (and I'm still not convinced that another switch would do more good than harm). I'm still deeply worried about the ability to use and improve Gerrit. It would be horribly painful to see all of the work switching from SVN to Git (a large portion of which was intended to allow easy code contributions) go to waste because this particular Git front-end has scared everyone away.
MZMcBride
On Fri, Jul 27, 2012 at 9:42 AM, MZMcBride z@mzmcbride.com wrote:
It feels a bit like buying a car that has no steering wheel. I didn't really want to overrun our bug tracker with Gerrit bugs, but I can certainly file a few against it.
Please do. I file every bug upstream as well, after it's been filed in our BZ.
I'm not trying to be an asshole, but I really don't understand how such a basic feature is missing (which is what I meant by "how does anyone use Gerrit?"). There's a dashboard feature that accepts user IDs to view a particular user's contributions to Gerrit, but without an index (or some other way to match IDs to usernames), I really have no idea how you're supposed to be able to look at a particular user's contributions.
Just as a minor nitpick--those dashboards aren't meant to be viewed by anyone other than the author themselves (which is why it's the main page when you login, as well as the default page for My -> Commits).
There's a couple of changes coming in 2.5 to this regard: 1) Personal dashboards will now be private -- the proper way to query someone's work is the "owner:" query in the search box. 2) With 2.5, you'll also be able to save "dashboards" or "queries" for pages you commonly look up (or just want to remember for later)
A quick note on the search field: it's super-powerful. I know I've pointed at the docs before, but I really encourage you to read them[0] if you're the type of user who likes doing these sorts of interesting queries. Also, in the merge queue for upstream right now (I'm praying it makes it into 2.5 before the branch) is search suggestions [1]. This should make it wayyy easier to find things you're looking for.
-Chad
[0] https://gerrit.wikimedia.org/r/Documentation/user-search.html [1] https://gerrit-review.googlesource.com/#/c/36932/
On Jul 27, 2012 6:58 AM, "Chad" innocentkiller@gmail.com wrote:
- Personal dashboards will now be private -- the proper way to query
someone's work is the "owner:" query in the search box.
As MZ and I found out last night, this is not the case. An owner: search only finds changes that person *started*, so it doesn't find changes by others they've contributed patchsets to. Searching for an e-mail address does get all changes someone's been involved in (even if they only comment on the change), I believe it's equivalent to reviewer:. But this is all far from obvious and took me a while to figure out, people who haven't used Gerrit before don't really stand much of a chance there.
Roan
Chad wrote:
Also, if anyone tells me that upstream is not active enough, I ask you to please look at a commit I made 2 days ago[0]. I know it wasn't earth- shattering, or even really important. What was important, is that it was reviewed and merged in *less than a minute* without any action on my part. All upstream contributions receive quite a bit of feedback, and things get merged into master every single day. I talk with the Gerrit guys constantly, and they've been nothing but supportive and helpful in both my questions and helping to resolve our issues.
That made me go to some bugs I experienced at the beginning, and look if they were thus fixed or not.
Issue 899: Tab to password field doesn't work if diff page is in background Filed: Apr 7, 2011 - http://code.google.com/p/gerrit/issues/detail?id=899
The bug is still open, although it got fixed. Maybe independently, perhaps unexpectedly due to rewriten code. It took ~1 year to fix since being filed.
Issue 1300: No history of removal actions Filed: Mar 25, 2012 - http://code.google.com/p/gerrit/issues/detail?id=1300
Pristine bug.
Bug 35468 https://bugzilla.wikimedia.org/show_bug.cgi?id=35468 Filed 2012-03-25 - Still happening.
The funny thing is that it is happening on gerrit.wikimedia.org but not on https://gerrit-review.googlesource.com or https://android-review.googlesource.com
So although they may be very responsive to patches, it may not be so easy to get the bugs solved (other than doing so ourselves, which as said, is not simple).
Just as a minor nitpick--those dashboards aren't meant to be viewed by anyone other than the author themselves (which is why it's the main page when you login, as well as the default page for My -> Commits).
Which is really annoying when you don't start from the home page. If I'm signing in from a change, that's because I want to comment/review on that change, not to go to a dashboard where it isn't even listed.
Please do. I file every bug upstream as well, after it's been filed in our BZ.
Sure. https://bugzilla.wikimedia.org/show_bug.cgi?id=38760
A quick note on the search field: it's super-powerful. I know I've pointed at the docs before, but I really encourage you to read them[0] if you're the type of user who likes doing these sorts of interesting queries. Also, in the merge queue for upstream right now (I'm praying it makes it into 2.5 before the branch) is search suggestions [1]. This should make it wayyy easier to find things you're looking for.
I don't feel comfortable with it. Too much magic, probably. It would benefit from having an interace like bugzilla advanced search, even if it gets coverted to the operators.
Le 27/07/12 15:42, MZMcBride a écrit :
I don't think it's fair to say that my posts have been unconstructive. I've tried to present actual problems (such as the lack of an authors list) that inhibit being able to effectively use Gerrit.
<snip>
To clarify, I was mostly ranting about the form. Your posts are definitely constructive and you are a huge asset to all the tech team by constantly reporting what is wrong and opening bugs. So keep please doing that :-]
On Fri, Jul 27, 2012 at 6:42 AM, MZMcBride z@mzmcbride.com wrote:
Antoine Musso wrote:
MZ, Do you even have a labs account? Your continuous rants are far from being constructive and makes everyone lose their time.
Nope. I looked at getting one once or twice, but the process seemed too bureaucratic and I ended up walking away. I imagine I'll make one once self-registration becomes possible.
Give me a break. You fill out a request that asks for like 4 pieces of information, then (usually the same day) someone creates an account for you, which sends you a password by email. It's seriously like 3 clicks.
This process is about 17234872748 times less bureaucratic then the svn request process was.
- Ryan
On Fri, Jul 27, 2012 at 6:42 AM, MZMcBride z@mzmcbride.com wrote:
For what it's worth, I think Ryan makes a compelling case for sticking with Gerrit (and I'm still not convinced that another switch would do more good than harm). I'm still deeply worried about the ability to use and improve Gerrit. It would be horribly painful to see all of the work switching from SVN to Git (a large portion of which was intended to allow easy code contributions) go to waste because this particular Git front-end has scared everyone away.
For what it's worth, this is pretty much exactly where I'm at right now. In spite of my defense of Gerrit, I'm not blind to it's manifold deficiencies in its current form. In addition to the problems for new volunteer contributors, there's a steep learning curve for new employees. I'm also worried about the steep learning curve anyone from our community (myself included) would have in getting set up to improve Gerrit through writing patches and plugins, though I'll take Chad at his word that it's really not as bad as many of us fear.
But, I'm also still not convinced that another switch would do more good than harm.
I think our best mitigation strategy is to do as good a job as we possibly can integrating Gerrit with GitHub, combined with other improvements to Gerrit.
Rob
On Fri, Jul 27, 2012 at 1:29 PM, Rob Lanphier robla@wikimedia.org wrote:
I'm also worried about the steep learning curve anyone from our community (myself included) would have in getting set up to improve Gerrit through writing patches and plugins, though I'll take Chad at his word that it's really not as bad as many of us fear.
I wrote a new plugin last night and pushed it today:
https://gerrit-review.googlesource.com/#/c/37030/
It took like...an hour? Yay for me ;-)
-Chad
On Fri, Jul 27, 2012 at 11:29 AM, Rob Lanphier robla@wikimedia.org wrote:
I think our best mitigation strategy is to do as good a job as we possibly can integrating Gerrit with GitHub, combined with other improvements to Gerrit.
One thing I don't think has been explicitly said yet, although Brion hinted at it early on is the nature of the gerrit-github integration. Gerrit serves the required workflow well for things like core and key extensions and puppet, so having changes made via gerrit reflected in a github view is great for outsiders to explore and experiment.
But it would also be great, especially for certain types of community contributions, if we could approve pull requests from github and have those reflected in gerrit.
I realize this is all hand-wavy and stuff, but as Brion pointed out, it's all git. With some thought behind the design, a two-way integration between gerrit and github seems like it would be possible and useful.
On Fri, Jul 27, 2012 at 1:55 PM, Chris McMahon cmcmahon@wikimedia.org wrote:
On Fri, Jul 27, 2012 at 11:29 AM, Rob Lanphier robla@wikimedia.org wrote:
I think our best mitigation strategy is to do as good a job as we possibly can integrating Gerrit with GitHub, combined with other improvements to Gerrit.
One thing I don't think has been explicitly said yet, although Brion hinted at it early on is the nature of the gerrit-github integration. Gerrit serves the required workflow well for things like core and key extensions and puppet, so having changes made via gerrit reflected in a github view is great for outsiders to explore and experiment.
But it would also be great, especially for certain types of community contributions, if we could approve pull requests from github and have those reflected in gerrit.
I realize this is all hand-wavy and stuff, but as Brion pointed out, it's all git. With some thought behind the design, a two-way integration between gerrit and github seems like it would be possible and useful.
Yes, I agree wholeheartedly. The main reason I've been holding off on doing the replication yet is that the replication system was split off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it up twice. Once we've got 2.5 running, this will become a *top* priority for me in our Gerrit setup.
Pulling stuff back in is probably doable (and I've heard rumors it's been done), but will require more investment.
-Chad
Yes, I agree wholeheartedly. The main reason I've been holding off on doing
the
replication yet is that the replication system was split off to a plugin
for
2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it
up
twice. Once we've got 2.5 running, this will become a *top* priority for me
in
our Gerrit setup.
Pulling stuff back in is probably doable (and I've heard rumors it's been
done),
but will require more investment.
-Chad
Not sure if anyone has mentioned this yet or not, but Gerrit 2.5 is getting pretty close to shipping too, so the wait shouldn't be too long. Skimming through their discussion on Google Groups [1] it appears as though as of July 11th there have been talks of starting releasing the RC versions of Gerrit 2.5. Not sure how long they usually end up staying in the RC stage before an actual release, but I can't imagine it is long.
Thank you, Derric Atzrott
Forgot the link...
[1] https://groups.google.com/forum/#!topic/repo-discuss/ZczND3xgtaw
Sorry about that, Derric Atzrott Computer Specialist Alizee Pathology
On Fri, Jul 27, 2012 at 2:08 PM, Derric Atzrott datzrott@alizeepathology.com wrote:
Yes, I agree wholeheartedly. The main reason I've been holding off on doing
the
replication yet is that the replication system was split off to a plugin
for
2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it
up
twice. Once we've got 2.5 running, this will become a *top* priority for me
in
our Gerrit setup.
Pulling stuff back in is probably doable (and I've heard rumors it's been
done),
but will require more investment.
-Chad
Not sure if anyone has mentioned this yet or not, but Gerrit 2.5 is getting pretty close to shipping too, so the wait shouldn't be too long. Skimming through their discussion on Google Groups [1] it appears as though as of July 11th there have been talks of starting releasing the RC versions of Gerrit 2.5. Not sure how long they usually end up staying in the RC stage before an actual release, but I can't imagine it is long.
Actually, a discussion started this morning again about what needs doing before the branch happens. The release manager for this cycle listed a couple of bullet points. That thread is here[0].
In general, the RC cycle is pretty quick--there's no firm rules, generally lasts a couple of weeks while any major remaining blockers are ironed out. I imagine we'll be seeing 2.5 final by late August at the latest.
-Chad
[0] https://groups.google.com/d/msg/repo-discuss/rxHwJJ2X9Ug/f7_6qMcsRYMJ
On Fri, Jul 27, 2012 at 10:59 AM, Chad innocentkiller@gmail.com wrote:
On Fri, Jul 27, 2012 at 1:55 PM, Chris McMahon cmcmahon@wikimedia.org wrote:
I realize this is all hand-wavy and stuff, but as Brion pointed out, it's all git. With some thought behind the design, a two-way integration between gerrit and github seems like it would be possible and useful.
Yes, I agree wholeheartedly. The main reason I've been holding off on doing the replication yet is that the replication system was split off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it up twice. Once we've got 2.5 running, this will become a *top* priority for me in our Gerrit setup.
Yay!
Pulling stuff back in is probably doable (and I've heard rumors it's been done), but will require more investment.
Cordova/PhoneGap hosts their primary repositories on Apache infrastructure, but keeps github mirrors and accepts pull requests through them.
You don't actually need special tooling; they do it pretty bare-bones by having the accepter pull the branch, merge and push it themselves: http://wiki.apache.org/cordova/CommitterWorkflow
Taking a pull request, cleaning it up, and popping it into gerrit for its final verification & +2 is at least no worse than taking a patch from Bugzilla or direct mail and sticking it in -- but should preserve the authorship info in the commit.
If we can devise tooling to make it even easier (paste in a pull request's URL and say "go"), that could be spiffy though.
-- brion
I did mention how Android used a homemade tool to do the reviews. It was introduced to me by a friend who is doing Android development for mobile phone companies. At first I was like: what about the existing google code or github? Then he explained me their pre commit workflow and it made me sure we wanted to use that. I think Ryan met the OpenStack folks who are using Gerrit. That probably convinced him it was the right tool for us too.
Actually, we started using Gerrit for Ops before OpenStack switched to it. It's just a happy coincidence.
- Ryan
On Jul 26, 2012, at 7:04 PM, MZMcBride z@mzmcbride.com wrote:
Rob Lanphier wrote:
A few of us are planning to meet Monday afternoon to figure out exactly what the rest of the process looks like, so that first deadline is going to be very important for understanding how many options we're truly considering.
Well, at least you're being open about not being open.
That's funny, because my experience is the exact opposite: this meeting is not in my calendar and I breathed a sigh of relief!
It's somewhat ironic that you have a group of people who regularly champion the virtues of open source software ("you can hack the code!") who have picked a software solution that's (apparently) nearly impossible to modify. Even eliminating Gerrit's vomit color scheme would be a vast improvement, but as I understand it, even basic CSS changes are a no-go with Gerrit.
Gerrit has templating support so basic CSS changes are not difficult and require no pushes to upstream Gerrit. Delta one strange thing in that the load order of the cascade in Gerrit is… wrong. My arguments with Gerrit are in fancier scripting UI that requires delving into GWT to get done. Chad mentioned that virtually nobody has played with either yet.
I'm lost as to how Gerrit was ever considered an option previously and how it's still an option on the table today, given its apparent inflexibility. Say what you will about MediaWiki's CodeReview extension, but on its worst day, it never garnered as much resentment as Gerrit.
The wiki page outlines exactly what went into the decision.
For instance, I like Phabricator. However very few of the requirements listed when this was discussed (in March) were in Phabricator so I understand why Gerrit was chosen even if I have a personal dislike for it. Phabricator has a high velocity of new features and support (actually about 2x Gerrit) and that is now changes. However, even so, that isn't the case (yet).
Also, consider that even if that is the case, it's neither Features engineers nor the community will be inplementing/maintaining whatever solution is used. The maintainers will be in Platform and Ops.
Now we can argue over whether the wiki page's criterias were the "right ones." (For instance, should the WMF adopt the Git/GitHub philosophy of un-gated reviews?) But since those criteria come from the practical reality on how code review is actually done and integrated currently, that's a different argument entirely to what code review tool is best for how we currently use it.
Gerrit won simply because it is designed to work the same way we were currently working… warts and all. But the landscape is changing and it's time to re-evaluate if a course correction is in order. Hopefully this won't be the last (if only because I don't think any other system is going to beat Gerrit spec-for-spec ATM).
On Fri, Jul 27, 2012 at 6:27 PM, Terry Chay tchay@wikimedia.org wrote:
Gerrit has templating support so basic CSS changes are not difficult and require no pushes to upstream Gerrit. Delta one strange thing in that the load order of the cascade in Gerrit is… wrong. My arguments with Gerrit are in fancier scripting UI that requires delving into GWT to get done. Chad mentioned that virtually nobody has played with either yet.
This is not what I said. I said injecting Javascript is possible as well, which Roan said he has experimented with before.
-Chad
On Fri, Jul 27, 2012 at 3:29 PM, Chad innocentkiller@gmail.com wrote:
On Fri, Jul 27, 2012 at 6:27 PM, Terry Chay tchay@wikimedia.org wrote:
Gerrit has templating support so basic CSS changes are not difficult and require no pushes to upstream Gerrit. Delta one strange thing in that the load order of the cascade in Gerrit is… wrong. My arguments with Gerrit are in fancier scripting UI that requires delving into GWT to get done. Chad mentioned that virtually nobody has played with either yet.This is not what I said. I said injecting Javascript is possible as well, which Roan said he has experimented with before.
I think we're already loading jQuery for Gerrit views in production, we're just not using it for anything yet.
Roan
wikitech-l@lists.wikimedia.org