If all we do is immediately copy the PR, submit it to Gerrit and close the PR saying "Please create a WMFLabs account, learn all of fucking Gerrit, and then continue on Gerrit to finalise the patch", then we should just kill PR now.

> ... Then, if a developer is not willing to learn > Gerrit, its code is probably not worth the effort of us integrating > github/gerrit. That will just add some more poor quality code to your > review queues.

I've been hosting my puppet-cdh4 (Hadoop) repository on Github for a while now. I am planning on moving this into Gerrit. I've been getting pretty high quality pull requests for the last month or so from a couple of different users. (Including CentOS support, supporting MapReduce v1 as well as YARN, etc.) https://github.com/wikimedia/puppet-cdh4/issues?page=1&state=closed I'm happy to host this in Gerrit, but I suspect that contribution to this project will drop once I do. :/

I wouldn't be that optimistic, maybe it would slightly increase. Having an account is one of the factors but I wouldn't underestimate user friendliness. The first time I tried to find the URL to clone a repo in gerrit it took me probably around a minute. On GitHub it probably took me 5 seconds.

Can we please be real here? The reason more contributors come in through GitHub than through Gerrit is because they *already have a GitHub

My browser is always logged into GitHub, and it's at the point where I can casually just fork a project and begin working on it, whereas with Gerrit you need to request an account. Like I said before, if you know how to use Git, you know how to use Gerrit (and the contra-positive is true as well). The primary thing holding

back is that it's confusing and not user friendly enough to make an

and get working. Imagine if people could sign into Gerrit using their Google accounts like Phabricator allows. I can guarantee participation would skyrocket. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Can we please be real here? The reason more contributors come in through GitHub than through Gerrit is because they *already have a GitHub account*. My browser is always logged into GitHub, and it's at the point where I can casually just fork a project and begin working on it, whereas with Gerrit you need to request an account.

+1 to me the need to create a gerrit account is a huge barrier for entry. I think we are missing out on attracting small but useful patches from developers who are not heavily invested in the project and have no wish to become regular core contributors...

I guess the whole idea of using GitHub is for public relation and to attract new people. Then, if a developer is not willing to learn Gerrit, its code is probably not worth the effort of us integrating github/gerrit. That will just add some more poor quality code to your review queues.

Hi, all! "Then, if a developer is not willing to learn Gerrit, its code is probably not worth the effort of integrating github/gerrit. That will just add some more poor quality code to you review queues." "Submitting a patch to gerrit and even fixing it after code review is not that hard. (Of course any more complicated operations like rebasing do suck, but you hopefully won't be doing that with your first patch.)" If I may, I'd like to respectfully disagree with these statements. For context, I'm a new Mediawiki developer who got a labs/Gerrit/LDAP account late last Fall. Since that time, I've submitted exactly five patches. Of those five, two were abandoned, once because Gerrit screwed up big time and once because someone merged another patch that superseded mine. Two have been merged, both were minor English translation changes. One is still sitting, waiting for me to re-base (It was my third patch… I'm scared to re-base because I don't want to screw something up). I did have to re-base on my first patch, thankfully; someone walked me through the process on IRC. I double-checked my code for consistency in all major browsers; in OSX, Ubuntu linux, and Windows; read and re-read the style guidelines. I can confidently say it was not poor quality. So, why am I not trying to learn Gerrit or try to submit patches? Because it's not worth my time. The interface is so far outside of what I'm used to, and it's just so touchy. By comparison, GitHub has a solid, no frills, Mac app that handles all of the important stuff. And, even when I committed to GitHub by command line, there was no way I could "Merge branch 'master' of ssh://gerrit.wikimedia.org:29418/mediawiki/core" by miss-typing a re-base <https://gerrit.wikimedia.org/r/#/c/37684/>. So, having GitHub is almost essential for folks who don't want to - or can't - understand or work with Gerrit. And closing off GitHub (or viewing their patches as "poor quality") will close of developers - like be - who are having trouble with Gerrit. Just my two cents. Thanks for reading. Matthew Bowker http://en.wikipedia.org/wiki/User:Matthewrbowker On Mar 8, 2013, at 11:20 AM, Bartosz Dziewoński &lt;matma.rex(a)gmail.com&gt; wrote: wrote: GitHub, and most of the patches I get are not even up to my standards (and those are significantly lower than WMF's ones). that hard. (Of course any more complicated operations like rebasing do suck, but you hopefully won't be doing that with your first patch.) _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Sat, Mar 9, 2013 at 12:15 PM, Yuri Astrakhan &lt;yuriastrakhan(a)gmail.com wrote: No. - Ryan

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Are there strong reasons do dismiss it that weren't stated in that page?

So, why am I not trying to learn Gerrit or try to submit patches? Because it's not worth my time. The interface is so far outside of what I'm used to, and it's just so touchy. By comparison, GitHub has a solid, no frills, Mac app that handles all of the important stuff. And, even when I committed to GitHub by command line, there was no way I could "Merge branch 'master' of ssh://gerrit.wikimedia.org:29418/mediawiki/core" by miss-typing a re-base <https://gerrit.wikimedia.org/r/#/c/37684/>.

In theory you are right - more folks = more awesomeness. In practice this involves a lot of effort, effort that people often are not willing to put in. Just look at our rather poor history with bugzilla patches (although things have improved)

On 2013-03-08 2:20 PM, "Bartosz Dziewoński" &lt;matma.rex(a)gmail.com&gt; wrote: wrote: GitHub, and most of the patches I get are not even up to my standards (and those are significantly lower than WMF's ones). that hard. (Of course any more complicated operations like rebasing do suck, but you hopefully won't be doing that with your first patch.) Making it easier to contribute is always going to cause more lower quality content to be submitted, since the unmotivated arent weeded out. But there are plenty of good people that also would get weeded out. I think this debate has a lot in common with the perenial debates on wikipedia to futher restrict anons and non autoconfirmed users. -bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[...]

The point I'm trying to make is that the problems with Gerrit are not problems with Gerrit, but actually problems with Git itself. If you can't handle the basics of Gerrit, it's because you don't know how to use Git. And at that point I don't see how GitHub is going to make things that much easier anyway.

As for the argument that this will lower code quality, I think the burden of proof is on those making that assumption.

> > [...]

> > The point I'm trying to make is that the problems with Gerrit are not > > problems with Gerrit, but actually problems with Git itself. If you can't > > handle the basics of Gerrit, it's because you don't know how to use Git. > > And at that point I don't see how GitHub is going to make things that > much > > easier anyway.

> ACK. Also I think, if you have mastered the MediaWiki code- > base to a degree where you can submit a patch, its actual > submission will be the least problem you've encountered :-).

I disagree and I have a very simple counter-point. Gerrit makes it basically impossible to work in a git-flow style ( http://nvie.com/posts/a-successful-git-branching-model/). From what I understand, rebasing and good branching strategies like git-flow simply don't get along.

[...]

I strongly disagree that Gerrit is harder to learn than Github. The only difficult thing to understand is the web UI, which takes only a few minutes to really get used to. Let's look at the biggest complaints:

This thread has probably reached that limit of fresh arguments. Can we continue with proper documentation, reporting and patches? We care about GitHub and we believe it is an important source of potential contributors. This is why we are mirroring our repos there, and this is why we are working on Bug 35497 - Implement a way to bring GitHub pull requests into Gerrit https://bugzilla.wikimedia.**org/show_bug.cgi?id=35497<https://bugzilla.… If you want to improve the path from GitHub to Gerrit please contribute to that bug report or e.g. in a landing page (at mediawiki.org or github.com) to help GitHub users interested in our projects. About the Gerrit UI, if you have specific complaints or enhancement requests please file them. We have been upstreaming reports and also patches. We are surely not the only Gerrit users thinking that GitHub does some things better so there is hope. But saying "it's ugly" doesn't help. On 03/09/2013 01:06 PM, Tyler Romeo wrote: What are the bottlenecks nowadays? If there are still any please file bugs.

On Fri, 08 Mar 2013 17:07:18 +0100, Antoine Musso &lt;hashar+wmf(a)free.fr&gt; wrote: This a hundred times. I manage a few (small) open-source projects at GitHub, and most of the patches I get are not even up to my standards (and those are significantly lower than WMF's ones). Submitting a patch to gerrit and even fixing it after code review is not that hard. (Of course any more complicated operations like rebasing do suck, but you hopefully won't be doing that with your first patch.)