Wikipedia iOS app moving to GH

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Wikipedia iOS app moving to GH

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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

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 <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

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 <[hidden email]> 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 <[hidden email]>
> 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

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 <
[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Fwd: Wikipedia iOS app moving to GH

Brian Gerstle
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 <[hidden email]>
Date: Wed, Jul 22, 2015 at 12:59 PM
Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH
To: Wikimedia developers <[hidden email]>


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 <
[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Ricordisamoa
In reply to this post by Brian Gerstle
  * 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Wikipedia iOS app moving to GH

Adam Baso
In reply to this post by Brian Gerstle
They're two separate lists. I believe most Reading engineers are on both
mobile-l and wikitech-l. Couldn't say so much for other people.

On Wed, Jul 22, 2015 at 10:16 AM, Brian Gerstle <[hidden email]>
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 <[hidden email]>
> Date: Wed, Jul 22, 2015 at 12:59 PM
> Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH
> To: Wikimedia developers <[hidden email]>
>
>
> 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 <
> [hidden email]> 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 <[hidden email]> 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 <
> [hidden email]>
> > > 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
> > > > [hidden email]
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > 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
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Gergo Tisza
In reply to this post by Petr Bena
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [WikimediaMobile] Wikipedia iOS app moving to GH

Brian Gerstle
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 <[hidden email]> wrote:

> On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Ryan Lane-2
In reply to this post by Gergo Tisza
On Wed, Jul 22, 2015 at 2:14 PM, Gergo Tisza <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Greg Grossmeier-2
<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 Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg                A18D 1138 8E47 FAC8 1C7D |

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Gergo Tisza
In reply to this post by Ryan Lane-2
On Wed, Jul 22, 2015 at 2:48 PM, Ryan Lane <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [WikimediaMobile] Wikipedia iOS app moving to GH

Ricordisamoa
In reply to this post by Brian Gerstle
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 <[hidden email]> wrote:
>
>> On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena <[hidden email]> 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
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Petr Bena
In reply to this post by Gergo Tisza
Force pushes can be disabled if you contact github support

On Wed, Jul 22, 2015 at 11:14 PM, Gergo Tisza <[hidden email]> wrote:

> On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Brian Gerstle
In reply to this post by Ricordisamoa
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 <[hidden email]>
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 <[hidden email]>
>> wrote:
>>
>>  On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena <[hidden email]> 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
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>>
>>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [WikimediaMobile] Wikipedia iOS app moving to GH

Faidon Liambotis
In reply to this post by Brian Gerstle
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 <[hidden email]> wrote:
>
> > On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena <[hidden email]> 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
> > [hidden email]
> > 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Antoine Musso-3
In reply to this post by Ricordisamoa
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Antoine Musso-3
In reply to this post by Petr Bena
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

MZMcBride-2
In reply to this post by Brian Gerstle
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikipedia iOS app moving to GH

Greg Grossmeier-2
<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 Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg                A18D 1138 8E47 FAC8 1C7D |

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12