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
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 bgerstle@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
I have no problem with that, as long as everyone with +2 keeps his access and someone manages developer account additions and removals. Oh, and when it syncs with phabricator tickets....
DJ
On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena benapetr@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 bgerstle@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
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_ml@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 benapetr@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 bgerstle@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
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 bgerstle@wikimedia.org Date: Wed, Jul 22, 2015 at 12:59 PM Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH To: Wikimedia developers wikitech-l@lists.wikimedia.org
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_ml@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 benapetr@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 bgerstle@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
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 bgerstle@wikimedia.org 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 bgerstle@wikimedia.org Date: Wed, Jul 22, 2015 at 12:59 PM Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH To: Wikimedia developers wikitech-l@lists.wikimedia.org
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_ml@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 benapetr@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 <
bgerstle@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
-- 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
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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
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 gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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 Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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 gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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 Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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 ricordisamoa@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 gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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 Mobile-l@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
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 ricordisamoa@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 gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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 Mobile-l@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
On Thu, Jul 23, 2015 at 2:08 PM, Ricordisamoa ricordisamoa@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 ricordisamoa@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 gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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 Mobile-l@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
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 gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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 Mobile-l@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
On Wed, Jul 22, 2015 at 2:14 PM, Gergo Tisza gtisza@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
<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
On Wed, Jul 22, 2015 at 2:48 PM, Ryan Lane rlane32@gmail.com wrote:
Some of the largest open source projects around are on github:
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/ae8bc0fe9adad... (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.
Force pushes can be disabled if you contact github support
On Wed, Jul 22, 2015 at 11:14 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@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
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>
* 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
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,
<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
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
<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
Brian and the Reading team:
On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgerstle@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
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 greg@wikimedia.org wrote:
Brian and the Reading team:
On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgerstle@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
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 bgerstle@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 greg@wikimedia.org wrote:
Brian and the Reading team:
On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgerstle@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
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 bgerstle@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 bgerstle@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 greg@wikimedia.org wrote:
Brian and the Reading team:
On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgerstle@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
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@lists.wikimedia.org