Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Antoine Musso
Le 22/07/2015 19:20, Ricordisamoa a écrit :
  * CR fragmentation
  * CI fragmentation
  * more reliance on proprietary software

This are all valid point and Brian Gerstle did a lot of work on trying
to reuse Gerrit/CI because he really wanted an opensource based solution
hosted on Wikimedia infrastructure.

It turns out that when doing IOS development you need the proprietary
XCode that only runs on Apple computer with Mac OS X.  That causes a few
challenges:

* where to host the Mac machines?
* how do we deploy and manage their configuration
* who is responsible for them
* what about security issues?

XCode has a few challenges that makes it hard to automatize and is
surely going to cost a lot of our precious engineering work to achieve
(if at all possible).

On the other hand, there are some providers of XCode that are integrated
with Github/Travis and grant us everything we need out of the box for
free/cheap price.

I am very grateful they evaluated and attempted to reuse the existing
WMF infra.  In the end Brian/mobile team choice is a pragmatic decision
and they pick the system that fulfil their needs at minimal cost.

cheers,

-- 
Antoine hashar Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Antoine Musso
Le 22/07/2015 13:39, Petr Bena a écrit :
 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.

There are a few reasons for not using GitHub that I keep mentioning:

* We need a reliable git services we can act on with minimum latency.
The reason we migrated out of SourceForge svn was because of some hours
of outage that prevented us from fixing the live site.

* The GitHub term of services [1] has a few restrictions that prevent
some our community members from contributing:
** You must be 13 years or older to use this Service.
** You must be a human. Accounts registered by bots or other automated
methods are not permitted.

At one point I think they requested you to put your real name.

[1] https://help.github.com/articles/github-terms-of-service/


But the real reason is why rely on a 3rd party when we can do it
ourselves?  Lot of old timers feel we should self host as much as possible.


 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.

I haven't watched the hour long video but I can quite a comment from
Linus explaining why he would not honor pull requests on the linux
GitHub project:

-8-8-8-8-8-
Linus wrote:
I don't do github pull requests.

github throws away all the relevant information, like having even a
valid email address for the person asking me to pull. The diffstat is
also deficient and useless.

Git comes with a nice pull-request generation module, but github
instead decided to replace it with their own totally inferior version.
As a result, I consider github useless for these kinds of things. It's
fine for *hosting*, but the pull requests and the online commit
editing, are just pure garbage.

I've told github people about my concerns, they didn't think they
mattered, so I gave up. Feel free to make a bugreport to github.

-8-8-8-8-8-

So in short the pull requests merge are quite awful and drop most of the
context.

Git built-in mechanism is http://git-scm.com/docs/git-request-pull

Original:
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
Linus followed up with more details in subsequent replies.


If you don't like git-review, which we borrowed from OpenStack and
serves thousands of professional developers there, feel free to amend it
or create your own wrapper on top of git push refs/for/branch


-- 
Antoine hashar Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread MZMcBride
Brian Gerstle wrote:
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.

Hi.

Where have you discussed this idea on-wiki or on Phabricator? Is there a
request for comments on mediawiki.org or a Phabricator Maniphest task
tracking this? Development teams are given fairly wide latitude, but it's
pretty difficult to argue against Faidon's position that development teams
shouldn't be unilaterally trying to move themselves to other platforms,
especially without any kind of proper discussion.

iOS is a proprietary operating system that serves a walled garden
environment. It's completely unaligned with Wikimedia's values and
mission. GitHub may be a better fit for you and your team (though there's
no real evidence of this), but the bigger and more pressing problem is
that your team shouldn't exist within the Wikimedia Foundation, in my
opinion. After years of discussion, I'm still unconvinced that mobile apps
are worthwhile. We should instead be focusing resources on killing
MobileFrontend and creating a proper mobile experience for our users.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Greg Grossmeier
quote name=Antoine Musso date=2015-07-23 time=15:35:29 +0200
 On the other hand, there are some providers of XCode that are integrated
 with Github/Travis and grant us everything we need out of the box for
 free/cheap price.

Which we could probably do from Gerrit:
https://lists.wikimedia.org/pipermail/qa/2015-July/002323.html

From my understanding that would give us:
* 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 GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Ricordisamoa
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:

The short answer is: yes. GitHub doesn't have the patch as a concept,
only commits, branches, and forks. We only plan on encountering forks when
merging volunteer contributions. Regardless of whether it's a fork, your
ability to push to a branch co Ed down to whether you're a collaborator
for that repo.

On Wednesday, July 22, 2015, Ricordisamoa ricordisa...@openmailbox.org
wrote:


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






___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Ricordisamoa

Il 22/07/2015 12:40, Brian Gerstle ha scritto:

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.


By the way, the Pywikibot team has been using Gerrit  Travis CI 
https://travis-ci.org/wikimedia/pywikibot-core for quite some time.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Brian Gerstle
On Thu, Jul 23, 2015 at 2:08 PM, Ricordisamoa ricordisa...@openmailbox.org
wrote:

 The even shorter answer is: you can't amend other people's pull requests
 without being explicitly allowed to.


Which is both good and bad. In gerrit, anyone can amend my patch,
potentially obliterating my changes, which means we need to manually sync
up to prevent conflicts and erasing each others' work:

I'm going to amend
OK!
Ok I amended!
Ok I'm stashing my changes, pulling, and re-applying!

As opposed to:

I pushed a commit to your branch
OK, I pulled the remote changes and had mine automatically rebased on top

Different strokes for different folks.




 Il 23/07/2015 11:57, Brian Gerstle ha scritto:

 The short answer is: yes. GitHub doesn't have the patch as a concept,
 only commits, branches, and forks. We only plan on encountering forks when
 merging volunteer contributions. Regardless of whether it's a fork, your
 ability to push to a branch co Ed down to whether you're a collaborator
 for that repo.

 On Wednesday, July 22, 2015, Ricordisamoa ricordisa...@openmailbox.org
 wrote:

  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





 ___
 Wikitech-l mailing list
 Wikitech-l@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Greg Grossmeier
quote name=MZMcBride date=2015-07-23 time=09:54:31 -0400
 Where have you discussed this idea on-wiki or on Phabricator? Is there a
 request for comments on mediawiki.org or a Phabricator Maniphest task
 tracking this? Development teams are given fairly wide latitude, but it's
 pretty difficult to argue against Faidon's position that development teams
 shouldn't be unilaterally trying to move themselves to other platforms,
 especially without any kind of proper discussion.

The previous(ly declined) discussion was at:
https://phabricator.wikimedia.org/T95749

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-23 Thread Petr Bena
Force pushes can be disabled if you contact github support

On Wed, Jul 22, 2015 at 11: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
 ___
 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] Wikipedia iOS app moving to GH

2015-07-23 Thread Brian Gerstle
The short answer is: yes. GitHub doesn't have the patch as a concept,
only commits, branches, and forks. We only plan on encountering forks when
merging volunteer contributions. Regardless of whether it's a fork, your
ability to push to a branch co Ed down to whether you're a collaborator
for that repo.

On Wednesday, July 22, 2015, Ricordisamoa ricordisa...@openmailbox.org
wrote:

 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



-- 
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] Wikipedia iOS app moving to GH

2015-07-22 Thread Brian Gerstle

 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
 it syncs with phabricator tickets


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...@gmail.com 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
 it syncs with phabricator tickets

 DJ

 On Wed, Jul 22, 2015 at 1:39 PM, 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.
 
  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 bgers...@wikimedia.org
  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@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
 ___
 Wikitech-l mailing list
 Wikitech-l@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Ricordisamoa

 * CR fragmentation
 * CI fragmentation
 * more reliance on proprietary software


Il 22/07/2015 12:40, Brian Gerstle ha scritto:

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



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Petr Bena
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 bgers...@wikimedia.org 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@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

[Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Brian Gerstle
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Derk-Jan Hartman
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 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.

 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 bgers...@wikimedia.org
 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@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Gergo Tisza
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Ryan Lane
On Wed, Jul 22, 2015 at 2:14 PM, Gergo Tisza gti...@wikimedia.org wrote:

 GitHub is focused on small projects; for a project with lots of patches and
 committers it is problematic in many ways:


Some of the largest open source projects around are on github:

https://github.com/saltstack/salt/pulse/monthly

https://github.com/docker/docker/pulse/monthly


 * poor repository management (fun fact: GitHub does not even log force
 pushes, much less provides any ability to undo them)


You can have force push to master disabled. Also their fork model (which I
dislike for other reasons) means you can limit access to the main fork to a
small set of people and require all pull requests to come from branches of
forks. It's the default model for basically every public github project.


 * 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)


You can manage that yourself through rebasing of PRs. That's completely
based on your workflow and what you require of contributors (or how you do
your merges).


 * no way to mark patches which depend on each other


Sure you can. Alll PRs are also issues and can be referenced by issue
number. If you mention the issue in a comment it adds a reference for you.


 * diff view works poorly for large patches


It's way better than gerrit. May not be better than phabricator, though.


 * 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)


You can delete and edit your comments. Draft comments in gerrit are an
anti-pattern IMO.

The biggest reasons to avoid github are the possibility of future lock-in
of the community, them possibly doing evil things (like source forge), and
the fact that it's a third party that's collecting information on our
community.

For all intents and purposes github is superior to gerrit and phabricator
in almost every way. It was avoided at Wikimedia in the past because of
privacy and security concerns.

- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Greg Grossmeier
quote name=Ryan Lane date=2015-07-22 time=14:48:07 -0700
 For all intents and purposes github is superior to gerrit and phabricator
 in almost every way. It was avoided at Wikimedia in the past because of
 privacy and security concerns.

Which have not disappeared nor been addressed.

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia iOS app moving to GH

2015-07-22 Thread Gergo Tisza
On Wed, Jul 22, 2015 at 2:48 PM, Ryan Lane rlan...@gmail.com wrote:

 Some of the largest open source projects around are on github:

 https://github.com/saltstack/salt/pulse/monthly

 https://github.com/docker/docker/pulse/monthly


Which does not necessarily mean it does not suck for them. Some large
projects are still on Sourceforge. Some large projects still use SVN. etc.
Change is hard.

 * poor repository management (fun fact: GitHub does not even log force

 pushes, much less provides any ability to undo them)



You can have force push to master disabled. Also their fork model (which I
 dislike for other reasons) means you can limit access to the main fork to a
 small set of people and require all pull requests to come from branches of
 forks. It's the default model for basically every public github project.


So force pushes can only obliterate feature branches, version branches and
whatnot.
(GitHub actually developed sane management of force pushes but only
included into their enterprise version. I guess that does not quite qualify
as doing evil things but still is unpleasant.)

 * 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)

 You can manage that yourself through rebasing of PRs. That's completely
 based on your workflow and what you require of contributors (or how you do
 your merges).


GitHub's PR interface sucks with a rebase-heavy workflow. There is no
indication that a commit is a rebased version of a former commit; former
commits disappear without trace; inline comments to former commits become
unintelligible. And you need force push to do it which has potentially
disastrous effects on GitHub.


  * no way to mark patches which depend on each other

 Sure you can. All PRs are also issues and can be referenced by issue
 number. If you mention the issue in a comment it adds a reference for you.


Which will not stop the CI infrastructure from testing your patch without
pulling in its dependencies, not will it stop a careless reviewer from
merging it without the dependencies.


  * diff view works poorly for large patches

 It's way better than gerrit. May not be better than phabricator, though.


Here is a patch I made a few days ago:
https://gerrit.wikimedia.org/r/#/c/225827/
Here is the same patch in GitHub:
https://github.com/wikimedia/operations-software-sentry/commit/ae8bc0fe9adad6f09f3da72a70e888798ff5a22e
(Warning: might crash your browser.)

 * 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)

 You can delete and edit your comments. Draft comments in gerrit are an
 anti-pattern IMO.


Deleting or reworking comments after email notifications have already been
sent out with them is much more of an antipattern.


Anyway, I did not intend to start a GitHub-vs-Gerrit deathmatch, nor to
criticize the iOS team's decision (at their team size GitHub makes perfect
sense IMO), just answer Petr's question about why don't we all just move to
GitHub.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l