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.

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 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.

You've already admitted that you don't use Gerrit, so do you have a really large stake in this?

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.

I know people complain about Gerrit a lot, but I personally find it much better than our previous toolset.

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.

On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride <z(a)mzmcbride.com> 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: 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. 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. 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).

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 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: 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 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 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. 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. 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 &lt;johndoe(a)example.org&gt; 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". As I said previously, huge effort involving multiple persons could be made branch. The answer is most definitely yes. We would need to open up branches creations to everyone. I tend to agree on that :-)

On Jul 27, 2012 1:11 AM, "Antoine Musso" > We have disallowed branch creation and merging for now, that can This is a great feature, but I think most people realize it exists. Was it ever publicized widely?

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 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.

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.

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

Issue 1300: No history of removal actions Filed: Mar 25, 2012 - http://code.google.com/p/gerrit/issues/detail?id=1300

Bug 35468 https://bugzilla.wikimedia.org/show_bug.cgi?id=35468 Filed 2012-03-25 - Still happening.

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).

Please do. I file every bug upstream as well, after it's been filed in our BZ.

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.

Antoine Musso wrote: 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'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.

On Fri, Jul 27, 2012 at 11:29 AM, Rob Lanphier &lt;robla(a)wikimedia.org&gt; wrote: 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 &lt;cmcmahon(a)wikimedia.org&gt; 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.

Rob Lanphier wrote: 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.

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.

On Fri, Jul 27, 2012 at 6:27 PM, Terry Chay &lt;tchay(a)wikimedia.org&gt; wrote: This is not what I said. I said injecting Javascript is possible as well, which Roan said he has experimented with before.