Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
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 bgers...@wikimedia.org wrote: FYI, spent some time this morning refactoring the epic https://phabricator.wikimedia.org/T98970, scope has been reduced to CI (moving CD into its own epic https://phabricator.wikimedia.org/T102547) and clarified/elaborated many other sections. On Thu, Jul 23, 2015 at 3:14 PM, Brian Gerstle bgers...@wikimedia.org wrote: 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 g...@wikimedia.org wrote: Brian and the Reading team: On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgers...@wikimedia.org wrote: 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. Given that, I am requesting you/your team create a set of KPIs to review in 3 or 4 months to determine if this change had the intended outcome. It's hard to make these things quantifiable as useful KPIs (that prevent eg gaming the system) but I think it'd be a good exercise for your team given your team's decision making process thus far. Please post those KPIs somewhere public and trackable (wiki or phab). Thank you, Greg -- Greg Grossmeier Release Team Manager -- 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 -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
FYI, spent some time this morning refactoring the epic https://phabricator.wikimedia.org/T98970, scope has been reduced to CI (moving CD into its own epic https://phabricator.wikimedia.org/T102547) and clarified/elaborated many other sections. On Thu, Jul 23, 2015 at 3:14 PM, Brian Gerstle bgers...@wikimedia.org wrote: 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 g...@wikimedia.org wrote: Brian and the Reading team: On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgers...@wikimedia.org wrote: 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. Given that, I am requesting you/your team create a set of KPIs to review in 3 or 4 months to determine if this change had the intended outcome. It's hard to make these things quantifiable as useful KPIs (that prevent eg gaming the system) but I think it'd be a good exercise for your team given your team's decision making process thus far. Please post those KPIs somewhere public and trackable (wiki or phab). Thank you, Greg -- Greg Grossmeier Release Team Manager -- 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
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: This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis). That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means amending patches becomes pushing another commit onto a branch. We've run into issues w/ rebasing amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit. On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com 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. 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 ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
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 g...@wikimedia.org wrote: Brian and the Reading team: On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgers...@wikimedia.org wrote: 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. Given that, I am requesting you/your team create a set of KPIs to review in 3 or 4 months to determine if this change had the intended outcome. It's hard to make these things quantifiable as useful KPIs (that prevent eg gaming the system) but I think it'd be a good exercise for your team given your team's decision making process thus far. Please post those KPIs somewhere public and trackable (wiki or phab). Thank you, Greg -- Greg Grossmeier Release Team Manager -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
Brian and the Reading team: On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgers...@wikimedia.org wrote: 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. Given that, I am requesting you/your team create a set of KPIs to review in 3 or 4 months to determine if this change had the intended outcome. It's hard to make these things quantifiable as useful KPIs (that prevent eg gaming the system) but I think it'd be a good exercise for your team given your team's decision making process thus far. Please post those KPIs somewhere public and trackable (wiki or phab). Thank you, Greg -- Greg Grossmeier Release Team Manager ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
Il 22/07/2015 23:43, Brian Gerstle ha scritto: This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis). That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means amending patches becomes pushing another commit onto a branch. We've run into issues w/ rebasing amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. With GitHub it is not possible to amend other people's patches, is it? We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit. On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com 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. 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 ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis). That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means amending patches becomes pushing another commit onto a branch. We've run into issues w/ rebasing amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit. On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com 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. 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 ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
