This will track tasks we need to do while migrating to GitHub.
Comparison added to https://www.mediawiki.org/wiki/Git/Gerrit_evaluation#2015_comparison_by_iOS_team
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T98970 iOS Continuous Integration MVP | |||
| Resolved | • BGerstle-WMF | T95749 Use GitHub as main repo for Wikipedia iOS |
Obviously mobile-tech requires a WMF Google domain account, but that Google Doc does as well. If you're trying to encourage community contributions this is not the way to go about it.
Also, almost all Wikimedia community developers contribute via Gerrit, not Github - it is the established and official tool for code review. A very small number of Wikimedia projects are active on Github.
We considered Differential/Arcanist, but @Qgil indicated it wasn't ready for widespread adoption and that it wouldn't support continuous integration. We also looked into upgrading Gerrit to improve the UX there, but were told that the Foundation isn't making any further investments in Gerrit since we're switching to Differential/Arcanist.
And so, we want to try GitHub to see if it makes managing our repo and doing code review less painful. We continue to support the development of more open solutions and would be happy to try them out as well. Until they're ready, we think this is a good compromise that has promise to help the team accomplish its mission: making a great Wikipedia iOS app.
Just to be clear: when the WMF migrates from Gerrit to Phab, you'll switch again (to Phab)?
Sorry, you haven't yet demonstrated how Gerrit is insufficient for your needs. I quote:
As an organization, we strive to use open source tools over proprietary ones, although we use proprietary or closed tools (such as software, operating systems, etc.) where there is currently no open-source tool that will effectively meet our needs.
Let's not forget that the iOS app was among the last Wikimedia projects to move from GitHub to Gerrit, not that long ago. It would be useful to know why @brion, Monte et al decided to do that move and whether those reasons would be still valid.
I personally prefer that all teams feel the same Gerrit pain and mirror their repos in GitHub equally. This consistency helps keeping the migration to Differential in a higher priority. If teams start going for local solutions then we will not solve the central problem.
The potentially valid argument here is for increased contributions from a non-Wikimedia community who are confused by Gerrit or believe the GitHub is the only place on the planet that they can contribute to FLOSS software projects. This was my motivation in publishing https://github.com/wikimedia/composer-merge-plugin as a GitHub only project. I hoped that it would get contributions from the existing Composer developer community that would otherwise not bother to mess with Gerrit. Thus far that magic community hasn't materialized. We have gotten a couple of feature requests and a pull request from the "outside world" but nothing to really justify the difference.
External contributions is discussed as pro in the google spreadsheet comparison (@dr0ptp4kt / @BGerstle-WMF could you make that doc world readable?) but that looks to be at least in part a reaction to insufficient configuration of the GitHub repo as the document mentions the pull requests have been received but ignored.
@bd808 I updated the doc sharing prefs so that anyone can see it.
Thus far that magic community hasn't materialized.
It's a hunch, albeit a strong one, that we will get more contributions. We'll have to wait and see.
@Qgil I didn't know the iOS project started on GitHub, but IMO that's irrelevant now.
As an organization, we strive to use open source tools over proprietary ones, although we use proprietary or closed tools (such as software, operating systems, etc.) where there is currently no open-source tool that will effectively meet our needs.
I guess what it comes down to is that the iOS team doesn't agree that we're making a good trade-off in terms of Gerrit vs. GitHub. IOW, the extra productivity we think we'd gain is worth compromising—given that we feel GitHub is still a positive force in OSS and that we have 0 commitment to it. If we're (very) surprised to find we preferred Gerrit, we'll switch back, relatively little harm done.
OTOH, if the Foundation values consistency so much higher than autonomy, I'd like to see a resolution which applies across all teams. Let the "Infrastructure" team decree a "blessed" toolset that we all use so we can put this to rest. Until then, Services is using (and supposedly enjoying) GitHub, therefore the iOS team would like to also exercise its autonomy to improve its development environment.
As far as switching back to Differential, we'd be happy to if we think it effectively meets our needs. Let us know how we can provide feedback. Also, we hope to keep our infrastructure sufficiently decoupled from VCS so switching can be as painless as possible.
EDIT: replaced reference to "C level" dictation of tools for a consensus-driven resolution
A while ago we lived in the world of Bugzilla. Bugzilla was, until we switched to Phabricator, *THE* official bug tracker for WMF projects, including all projects by WMF Engineering. Some teams chose to use third-party tools like trello/mingle, but that did not obviate them from using and responding in BZ adequately.
That is a decree by both "the C-Level" (that quote from Lego was written by Sue and Erik, two people no longer here ("I'm not dead yet!" from Erik not-withstanding), but still the policy of the organization).
We, the infrastructure team (and specifically RelEng and Operations) actually do decree that any deployed code must come from Gerrit for MediaWiki and extensions. This is for a number of reasons not worth going into here. The special case of the iOS app is just that, a special case, that we should or should not make based on a number of factors. The team's (yet unfounded and there's very little preliminary data to support it, only data that disproves it (other team's experiences)) perception of potential contributions from the github world is only one of those.
I hope we all remember the reason we chose Phabricator: to reduce the splintering of WMF engineering teams across multitudes of tools.
Remember that all of the work you do as a WMF employee is actually in support of the Wikimedia (big C) Community. The community is pretty clear, and so is the WMF, that community members need to be able to participate in our projects using WMF-hosted services; all exceptions to that rule are exceptions. We strive to ensure the privacy and security of our users to a much higher degree than almost any other web project and to force our users/community members to agree to a much less stringent TOS (github's) to contribute is seen as a failure by many. Again, there are exceptions but exceptions do not make the rule.
I fully acknowledge and respect the thought that the iOS and Services teams put into their decision to use github, but I think it only points out the problem that should be fixed intead: We need to properly support the CI work at WMF, instead of continually denigrating it and ignoring it.
On another note: Would you (iOS app devs) be interested in using Phab's Differential instead (ie: be an early adopter)?
I sincerely hope that this is not the general feeling for how we should facilitate our development teams at WMF. We are responsible for developing, building, and maintaining a site and apps for millions of users around the world. To think that some employees view it in their best interest to actively worsen the workflow of our development teams in order to get organizational support for adopting a tool, is just insane.
@Qgil I realize how this comment reads - and a flame war is not what I am looking for, but I hope you can appreciate my reaction to this comment.
This consistency helps keeping the migration to Differential in a higher priority. If teams start going for local solutions then we will not solve the central problem.
I’m honestly surprised to read this this. I thought Phabricator had the support of the WMF leadership, employees, and community. Do you feel that you do not have enough support for Phabricator? If so, that is another issue. We should solve that so you have the resources you need to get all Phabricator tools up and running for the WMF organization.
Teams should not have to demonstrate how painful Gerrit is on a daily basis so you can get the support you need. I really do want us to provide as much support to the Phab team as needed to get it where it needs to be for all teams at WMF. Please let us know what we can do to get you the support you need.
We would need a few things. One would be CI support. We would also want to be able to support a workflow where we can accept pull requests on Github.
We would have to discus it further as a team, but that would be a good place to start.
This is easily accomplished with gerrit, differential or any other primary git repo host. See https://help.github.com/articles/checking-out-pull-requests-locally/. Pull from github, push to wherever, profit.
Thank your saying this. We are really trying to modernize development processes on the mobile team. CI is an important part of this. With native development, we have so many fiddly pieces in the release process tool chain. Getting CI setup to streamline these processes has been and will continue to be a huge timesaver and reduces the possibility for making simple mistakes.
Supporting CI should be central to our infrastructure work. I hope this discussion highlights that need even further.
Gerrit is not very well liked by anyone I've talked to. I think we nearly all agree that phabricator + differential is the way forward. Currently there is not really anything major holding us back from moving to differential and we have a rough idea of how that process can proceed as a natural progression rather than a huge migration involving organization-wide disruption.
The strategy that I have advocated for a while now, and I think it is the most obvious way forward now, is to simply switch people from gerrit to differential, one team at a time, and in multiple phases:
A little more context for what @greg and @Qgil are advocating: We have a tiny team to work on a lot of different projects. I'm pretty much the only person who will be able to devote significant amount of time to phabricator in the next few months. So there is a very big constraint on how much can get accomplished but we are also very motivated and confident that phabricator is the right solution to the code review problem, and many others as well. And we would like to avoid doing things twice if we can help it. And additionally, we very much are in need of early adopters to take the plunge and show others that it's not so scary switching from gerrit to differential. All of these factors align with encouraging you guys to move to phabricator rather than github.
tldr; I don't know much about your specific process but I'm personally motivated to help make it better. Educate me on your needs and I'll do everything I can to accommodate those needs in phabricator and will incorporate what I learn into the ongoing development of our tooling and workflows as we continue to incrementally improve on deployment and CI tooling.
@Fjalapeno: those of us who aren't dealing with your day to day challenges have very little visibility into what the pain points are for your team. It is the job of release engineering to support you and help facilitate the whole process which you are trying to modernize.
So to get the most benefit from us as a support team for your development process, please educate us as much as you can about what are the pain points currently, and what direction do you see as the best way forward. We may not agree with every detail of your conclusions but we will definitely do our best to understand your needs and advocate for solutions that address the problems you are facing - and do everything in our power to make the whole process better - so that your day to day work is more enjoyable and productive and with any luck we will continuously improve our processes as well as our infrastructure, to provide better support for the needs of each individual and team alike.
Anyway, that's my personal viewpoint on our role as a support team for all of wikimedia engineering. I'm new to releng and I think we have along way to go before this is fully realized so that we are all being most effective at our jobs - there are a lot of points of friction that still need to be eliminated but I take the challenge very seriously and I welcome your feedback and guidance on what I can do to help you get your job done more effectively and (this part is important) also more enjoyably - dealing with stupid roadblocks that stand in the way of getting your code tested, reviewed, and released into the hands of end users can really take a lot of the fun out of our work - and I hate it when I see others dealing with this as much as I hate dealing with it myself. Eliminating friction from the development process is my #1 personal priority, and I believe Greg supports me on this being a high priority for release engineering as a team.
</rant>
So, while I will not stand in your way or try to talk you out of migrating to github, I will certainly be more useful to you if you tell me how I can make differential work for your team so that your needs are adequately addressed by the solution we are developing.
The fact that the project started in GitHub is irrelevant indeed. The fact that the team decided to move from GitHub to Gerrit is not. Those who cannot remember the past are condemned to repeat it. :) Asking @brion, @Mhurd and @yuvipanda should not be difficult?
@Fjalapeno, although your arguments are correct, it is also correct that Wikimedia should offer a simple and consistent developer experience to all technical contributors. Different teams using different tools does not help this goal. Gerrit is a pain, and I'd rather focus the energies of the discontents in a single alternative.
FYI I've sent most of you a calendar invite to discuss this face-to-face. If you didn't get an invite and would like one, please reach out to me via email or IRC. I'll update this ticket as a result of the discussion.
Thanks for the response @mmodell
There’s a lot in there - so I won’t unpack it all. But I think you will find our team goals are not that far from yours. It might be better if we discus further over hangout with the team. Especially so we can help you understand what our needs are. Brian setup a meeting so we can discus.
To answer one of your questions - yes, we would really love to evaluate Diffusion and provide you feedback so we can make the product not only better for us, but also the entire organization. Please send the iOS team invitations to the beta! Actually, I am sure the Android team would like to look at it as well.
We spent a lot of time evaluating our needs and the different tools - and evaluating Differential deserves us putting in the equivalent effort. So this won’t be an "off the cuff" decision. After we put in the time working with and understanding the Differential, we can make an informed decision to see if we can move to Differential while it is still in beta.
Just a note: This ticket is already in scheduled in the current sprint, so we while we will definitely be evaluating and considering Differential while it is beta, we won’t be derailing work already in process.
Thanks again to everybody for their feedback - I really hope this results in us making Differential a better tool for the entire organization.
Sometimes scheduled things must be delayed; to assume good faith of everyone involved I don't think stating "we're going to do something regardless of this discussion" is fruitful. We're all professionals here and are working to do the right thing.
Just want to quickly assure people I haven't forgotten about this and will follow-up soon with our next steps—including a recap of the hangout we had yesterday. I might get to it later this evening but might not happen until tomorrow morning.
Marking this as declined and taking out of current sprint. To put it somewhat briefly:
We'll continue to plan & track work in Phab, so stay tuned for further updates.
...or not.
Guess I should have seen that one coming: https://lists.wikimedia.org/pipermail/wikitech-l/2015-July/082490.html
Updating task status to reflect intention.
I fail to see how this task is resolved. Is Wikipedia iOS now using GitHub as its main repository? Have the checklist items listed in the task description been resolved?
Although we are moving to GH, this task is obsolete. New tasks were written to be more focused on desired outcomes and technology-agnostic—to better evaluate options w/ QA & RelEng. Since we're moving forward with Travis (and GH), I'm marking this task as Invalid in favor of the main user story, T93078:
"As a Wikipedia iOS project contributor, my changes are automatically tested as part of code review."
That said, satisfying the acceptance criteria for that story will involve using GH as the main—but not exclusive—repo; as announced in the aforementioned email.
On second thought, re-opened so we can track all the little things we need to do while migrating (verifying owners, README, etc.).
One understressed issue with using GitHub is that code paid for by the WMF and developed there tends to get lost forever. Countless products by WMF contractors, in particular, have been thrown on GitHub and since forgotten.
I try to keep lists at https://www.openhub.net/orgs/wikimedia but it's quite hard.
@Nemo_bis FWIW we'll be dumping to Gerrit every release. Are you saying we should have other backups on WMF hardware as well?
@Nemo_bis Are there any "GH" usages elsewhere that you wanted eliminated, or only on this task (which you seem to have already done)?
You're probably already aware of this but maybe it will be helpful to mention:
Phabricator repositories can be easily mirrored to github (with phabricator as the master) or mirrored from github (with phabricator as slave)
This could, perhaps, help with visibility as well as having the code live on WMF-hosted infrastructure, without interfering with a github-centric workflow.
Moving away from gerrit is still a high priority goal, at least for the Release-Engineering-Team team. Any effort that would be put into mirroring things to gerrit should instead be directed towards using diffusion.
My concern about repositories getting lost was a generic one, sorry if it's a tangent. For the main Wikipedia iOS repo there will be no such problem; it's the proliferation of GitHub repos which easily gets problematic.
@Nemo_bis FYI, we hope (in the long term) to eventually modularize the code base into multiple "component" repos which are available as standalone libraries (similar to what WordPress Mobile is doing). Hopefully orphaning the code won't be a problem. I'm sure the iOS team will experience turnover (it's inevitable), but that shouldn't affect where the code lives or the fact that the iOS team owns it. If something more drastic occurs... well we can cross that bridge when we come to it. Until then, we have very clear "ownership" of this pocket of WMF software, so you needn't worry about it getting lost (unlike other components which have no clear owner).
mirrored from github (with phabricator as slave)
@mmodell veryyyy interesting... we should talk :-). we're still supporting gerrit as a best-effort, doing manual code drops every release. This could be obviated by auto-mirroring back to Phabricator. We could also use this as a way to dip our toes into the water w.r.t. Phabricator, though it will be hard to make it our primary until CI capabilities reach parity. I pinged @QuimGil about it, but we are missing ties between CR and Phab planning. Would you guys be able to help us with that?
Just to clarify, Release-Engineering-Team and @mmodell are the ones driving the plan to implement code review in Phabricator. @Aklapper and me will help where needed.
I can easily set up the repository mirroring, all I need is a list of the following for each repository:
Just open a task with the details and assign it to me, I'll be glad to get it all set up.