I have no problem with that, as long as everyone with +2 keeps his access and someone manages developer account additions and removals. Oh, and when it syncs with phabricator tickets.... DJ On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena <benapetr(a)gmail.com> wrote:

sorry, didn't hit reply-all. (these lists aren't a subset of each other, are they?) Also, we're losing IRC notifications, but that should be easy enough to add back via fastlane. ---------- Forwarded message ---------- From: Brian Gerstle &lt;bgerstle(a)wikimedia.org&gt; Date: Wed, Jul 22, 2015 at 12:59 PM Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH To: Wikimedia developers &lt;wikitech-l(a)lists.wikimedia.org&gt; I have no problem with that, as long as everyone with +2 keeps his access This should already be the case for the main iOS engineers, but I've made a ticket <https://phabricator.wikimedia.org/T106547> to make sure people don't slip through the cracks. Oh, and when Phabricator ticket sync is something we're sad to lose, but it's part of the trade-off we're making. That said, it was only slightly beneficial as we relied more on cards being in a "Code Review" column (w/ a WIP limit) than looking at the gerrit updates on the cards themselves (which aren't visible from the board view). Not that GH will make this any easier, but we're not losing too much here, IMHO. On Wed, Jul 22, 2015 at 8:01 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml(a)gmail.com&gt; wrote: > I have no problem with that, as long as everyone with +2 keeps his access > and someone manages developer account additions and removals. Oh, and when > DJ > > On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena &lt;benapetr(a)gmail.com&gt; wrote: > > > Good job, you aren't the only one. Huggle team is using it for quite > > some time. To be honest I still feel that github is far superior to > > our gerrit installation and don't really understand why we don't use > > it for other projects too. > > > > The GitHub's pull requests are more compliant with original git > > philosophy of Linus, see this video: > > https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient > > replacement to our current "git-review" mechanism, which is very > > complex and unfriendly to new developers who probably find it very > > difficult to use. > > > > On Wed, Jul 22, 2015 at 12:40 PM, Brian Gerstle &lt;bgerstle(a)wikimedia.org&gt; > > wrote: > > > Hey everyone, > > > > > > I'm writing with plans for the Wikimedia iOS engineering team to move > its > > > workflow to GitHub with Travis CI, much like RESTbase. > > > > > > The Wikimedia iOS engineers have been maintaining their own CI and > build > > > server and using Gerrit for code review. The more time efficient and > > > commonplace approach for open source iOS software development leans > > heavily > > > on GitHub with Travis CI instead (e.g., WordPress[0][1] and > > Firefox[2][3]). > > > By using GitHub with Travis CI, the team believes it will work faster, > > > improve testing, grow developer confidence in making code changes, and, > > > most importantly, deploy fewer bugs to production. > > > > > > For builds requiring sensitive information (e.g., prod certs), will > > > continue to run on WMF's Mac Mini. As is done for Android, when betas > are > > > pushed, the team will notify mobile-l. > > > > > > Feel free to reply or email me directly with any questions or comments. > > > > > > Regards, > > > > > > Brian > > > > > > 0: https://github.com/wordpress-mobile/WordPress-iOS > > > 1: https://travis-ci.org/wordpress-mobile/WordPress-iOS > > > 2: https://github.com/mozilla/firefox-ios > > > 3: https://travis-ci.org/mozilla/firefox-ios > > > > > > -- > > > EN Wikipedia user page: > https://en.wikipedia.org/wiki/User:Brian.gerstle > > > IRC: bgerstle > > > _______________________________________________ > > > Wikitech-l mailing list > > > Wikitech-l(a)lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena &lt;benapetr(a)gmail.com&gt; wrote: GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways: * poor repository management (fun fact: GitHub does not even log force pushes, much less provides any ability to undo them) * noisy commit histories due to poor support of amend-based workflows, and also because poor message generation of the editing interface (Linus wrote a famous rant <https://github.com/torvalds/linux/pull/17#issuecomment-5654674> on that) * no way to mark patches which depend on each other * diff view works poorly for large patches * CR interface works poorly for large patches (no way to write draft comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity) * hard to keep track of cherry-picks

Il 22/07/2015 23:43, Brian Gerstle ha scritto: With GitHub it is not possible to amend other people's patches, is it?

The even shorter answer is: you can't amend other people's pull requests without being explicitly allowed to. Il 23/07/2015 11:57, Brian Gerstle ha scritto:

Hi Brian, The arguments for/against GitHub etc. were discussed at length across all of our engineering staff & community, exactly 3 years ago, which reached consensus: https://www.mediawiki.org/wiki/Git/Gerrit_evaluation#GitHub In my opinion, this is not something that should be addressed on a per-team basis (and especially not by making the decision first internally in the team and then announcing it to the wider audience as a done deal). Individual and team-wide preferences should be considered as input to the wider discussion but ultimately people should yield to the collective decision. A per-team decision for critical tooling like the one you just announced would be inappropriate in a corporate setting, and is even more so in a community-facing organization. All this applies to both our Git tooling as well as CI, for which is worth noting that there are people in the foundation working on it full time. It's not very different than our issue tracking tooling either, for which we already know the huge pains that we've suffered in the past by having it fragmented across multiple different tools that each individual team picked. We can always revisit past decisions and reopen past discussions (to some extent, it's a sign of health) but your way is not the way to do this, IMHO. Best, Faidon On Wed, Jul 22, 2015 at 05:43:07PM -0400, Brian Gerstle wrote:

<quote name="Ryan Lane" date="2015-07-22" time="14:48:07 -0700"> Which have not disappeared nor been addressed. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Force pushes can be disabled if you contact github support On Wed, Jul 22, 2015 at 11:14 PM, Gergo Tisza &lt;gtisza(a)wikimedia.org&gt; wrote:

<quote name="Antoine Musso" date="2015-07-23" time="15:35:29 +0200"> Which we could probably do from Gerrit: https://lists.wikimedia.org/pipermail/qa/2015-July/002323.html * Gerrit for code review (non-GitHub) * Travis for iOS build/tests What else do we need? Obvious statement: if we go this route, enabling TravisCI integration with a Gerrit hosted project will only be after careful review and approval for situations (like iOS) where our in-house expertise and infrastructure is not sufficient. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

<quote name="MZMcBride" date="2015-07-23" time="09:54:31 -0400"> The previous(ly declined) discussion was at: https://phabricator.wikimedia.org/T95749 Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

The (rough) epic definition is already on Phabricator: https://phabricator.wikimedia.org/T98970. I've defined some metrics there already, but admittedly—and thanks for calling us out on this—we don't really have baselines*. I think there are some feasible ways to get a rough starting point, which I can brainstorm w/ the team. We were planning (or I should say, I was hoping) to gather more code metrics anyway, so I'm glad to have an excuse to hook it up sooner ;-). FWIW, I also think having patches tested as part of code review <https://github.com/bgerstle/apps-ios-wikipedia/pull/3> would also work as a sufficient definition of success. Our goal here is to do that as quickly, easily, and cheaply as possible so we can get back to focusing on the app. * I think it's fair to say that the coverage at point of migration was already low (~10% based on my Travis-covered fork) and hasn't changed much. On Thu, Jul 23, 2015 at 2:04 PM, Greg Grossmeier &lt;greg(a)wikimedia.org&gt; wrote: -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

Hello again! Writing to inform that the move has happened. Here's a quick breakdown: - GitHub repo: https://github.com/wikimedia/wikipedia-ios - Main repo for development, code review, and continuous integration (via Travis & CodeCov) - Gerrit repo: https://gerrit.wikimedia.org/r/#/admin/projects/apps/ios/wikipedia - Code drops every release, developers will still get notifications from patches submitted - *new* Phabricator repo: https://phabricator.wikimedia.org/diffusion/APIOS/ - Automatically synced with GitHub (Phab is the slave). Mostly just as "redundant storage," not sure if we'll support any code review here for the time being (mostly due to iOS team unfamiliarity) Hope to see a pull request (or patch) from you soon! Brian On Fri, Jul 24, 2015 at 10:25 AM, Brian Gerstle &lt;bgerstle(a)wikimedia.org&gt; wrote: -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle