lists at nadir-seen-fire
Jul 27, 2012, 12:13 AM
Post #9 of 36
On Thu, 26 Jul 2012 23:43:51 -0700, Ryan Lane <rlane32 [at] gmail> wrote:
> On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride <z [at] mzmcbride> 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
>> people, I think I would use Gerrit more if it weren't so awful. Just
>> 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:
>> 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:
> 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
> 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
- -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
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
>>> 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
>> precedence, for example). The fact that they're not runs against a lot
>> 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
>> Saturday: <https://bugzilla.wikimedia.org/show_bug.cgi?id=37628>
>> a Git/Gerrit/Labs account requires human intervention"). I realize that
>> and the other ops folks are busy, but if someone could at least explain
>> current process, it would give volunteer developers a fighting chance of
>> helping out. Not having the faintest idea how the current account
>> 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 (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Wikitech-l mailing list
Wikitech-l [at] lists