Corey/Brian joined in Dec 2014/Jan 2015. "How do you guys do build and testing?" Answer was manually.
Got checklist going. Goal was to automate.
Can not build at all on Linux box; need to be built on OSX.
First step was to have a Mac mini running Jenkins; downloaded source and pushed build somewhere
Wanted to run tests on the box. Travis and Github entered the conversation.
Brian Gerstle: ^ to be clear, we could run tests on the box, but we were getting 0 feedback where we really needed it: in the code review system (Gerrit)
Lots of discussions happened during the May 2015 hackathon in Lyon
Discussed costs.
Brian Gerstle: ^ we roughly discussed implementation details, enough to establish that DIY would have been a non-trivial, long-term undertaking which neither iOS nor RelEng/QA were interested in shouldering in the near term.
Antoine Musso: caused a few operating challenges such as how to maintain yet another OS (Mac) and how well Xcode could be driven from CI/Jenkins. We discussed used of alternative third parties.
Greg: Nobody wants to maintain Mac minis. neither Operations or RelEng can devote time to support Mac minis,
especially for an app that has relatively few page views. Was not going to make the cut in the next year.
"Isn't there a way for Travis to work with Gerrit?"
Brian isn't aware of a Travis/Gerrit option. Would have been open to it, but would have been a lot more work.
Could shift to that, but would need training to get iOS team up to speed with gerritt
C Scott sent a proof of concept to the QA mailing list of doing that, so that might be an option.
Greg: No communications iOS-RelEng in last month or so.
Jumped from "considering" to "decided" with no public conversation. Greg: "Just not how things are done here"
There was silence after the hackathon. Brian tried indirectly to get the conversation going again.
Team still feeling the pain of not having integration.
This meeting is the first time Brian is hearing that RelEng won't support iOS. Would have helped to have heard that earlier.
Best option seemed to be Travis (which is free) which we already know.
Saw NPM option (from C Scott), but not reasonable to expect the iOS team to put in that level of effort.
One good outcome: Have a plan to handle this kind of conversation.
Greg had really hoped to be able to support iOS, but reality has set in. Agree would have been nice to know/say earlier.
Apologized for not expressing earlier that they couldn't, since he really would like to.
Action item after Lyon was: How to integrate OSX machine into the build chain. VPS is closed source.
Could buy and maintain our own machines, but high staff costs. Outsource to Travis w/virtual OS machines.
Travis only supports github; others support systems like bitbucket, but still the same problem (not gerritt).
After a couple weeks of distractions, Brian contacted people directly, but didn't get responses.
Turned to Adam, and just tried to move forward.
Responses to earlier email (e.g. "your team shouldn't exist") were a deterrant to sending a wider email, and
contributed to only reaching out to individuals at this point.
Reminds G of MP4 discussion. That was a stereotypical discussion for that kind of proposal (proprietary vs. free).
Robla gave great advice: There will always be those who communicate badly and sound like trolls. They (sometimes) also say useful things. So ignore the 90% useless and focus on the nuggets of usefullness even though it's hard to do.
Conscious decision to send "notification" email rather than "RfC".
Intent was: "We're going to do it unless someone gives us a better idea"
Greg requested a public conversation before he left. Why didn't that happen?
(If there was a clear answer, I didn't capture it in my notes)
^ BG: My perspective on this is: after my initial attempts to restart the conversation w/ Greg (who then looped in others), I got no response, so asked Adam for support. From that point on all communications from Greg were "arbitrated" by Adam.
Adam: Tone of email could have been different. Should have emailed Greg with the message to get feedback.
If we can't come to agreement on something like this, it should get escalated as necessary.
(when pragmatic option is at odds with values of the org)
Corey: This wasn't a sudden thing. Had dragged on for months. This was the culmination.
At some point, you have to get pragmatic. The input had trailed off, with breakdowns in communication all over the place.
Original ticket was declined abruptly.
Bryan: Be more responsive when people reach out for help. Look for alternatives rather than just saying "no"
Brian: Maybe look at another case that went differently: crash reporting.
The main difference is that someone (Yuvi) experimented in labs, which led them to a more open provider
Another example is where someone pointed out an open code coverage option.
Good part of the new staff guidelines, "commitments instead of complaints"
Commit to trying to keep the conversation open, but find a way to get to a compromise.
Github is a lightning rod, for a variety of reasons.
Greg: We are frustrated because we want away from Gerritt, but hard to do so
