> But do we have a plan for improving Gerrit in a substantial way? > Gerrit releases often and every release is quite better than the last. Chad can and has been pushing changes upstream. OpenStack (which has 180+ companies that can potentially assist), QT, and other substantial communities are using and are improving Gerrit.
> I can get behind the decision to use a currently substandard tool in order > to preserve Wikimedia's long term freedom. But to stick with Gerrit, we > must have a plan for fixing it that does not simply declare that the > ability to make changes means that the magic FOSS fairy will make it so. I > don't know what it would take -- maybe a weekend in SF where we invite > every Java and Prolog expert we can find? Paying a contractor or two to > make the necessary fixes? > Make sure to add any complaints to the wiki page (http://www.mediawiki.org/wiki/Git/Gerrit_evaluation#The_case_against_Gerrit). Many claims that "Gerrit sucks" tend to be due with misunderstandings of how Gerrit works. Many other claims are due to our workflow or our restrictions with access currently. Of course, many claims are legitimate and we are reporting the issues, tracking them upstream, and in some cases pushing in fixes. There's some substantial downsides to Gerrit, but I don't see alternatives that don't have equally as substantial downsides. Sumana listed numerous downsides to using Github. We can't fix the downsides in Github; we at least have the ability to do so with Gerrit. Just to drive this point home a little more, let's look at OpenStack's reasoning with going with Gerrit (rather than Github): https://lists.launchpad.net/openstack/msg03457.html > This isn't just about attracting scores of new volunteers or having a > "reputational economy". It's a push for change driven by the fact that > Gerrit seriously undercuts developer productivity and happiness. When we've > got so many difficult, ambitious projects under way, I think those are two > things we should be prioritizing. By that measuring stick, Gerrit fails > miserably and GitHub is a winner. > I'm not sure I agree with the claim that this seriously undercuts productivity. Is there any data to back this up? I'd like to add a couple major downsides to using Github: 1. It would be worrisome from a security point of view to host the operations repos on Github. I think it's very likely that those repos would stay in Gerrit if the devs decided to move to Github. This would mean that we'd have split workflows, forcing developers to use both. 2. We can't use github enterprise: https://enterprise.github.com/faq#faq-6 - Ryan _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
