Wikimedia Apps/Team/Retrospectives/Retrospective-iOS-Github-2015-08-03

iOS Github RetrospectiveEdit

  • Invited: Adam Baso, Brian Gerstle, Bryan Davis, Dan Duvall, Greg Grossmeier, Corey Floyd, Monte Hurd
  • Attended: Adam, Brian, Bryan, Greg, Corey
    • (Through a miscommunication/oversight, Max Binder didn't get invited)
  • Facilitator: Kevin Smith

History:Edit

  • 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.

DiscussionEdit

  • 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

Takeaways:Edit

  • Flag issues like this. Be aware of lightning rods. Be realistic about resource options and be willing to say "no" when necessary.
  • Public/open/wider discussions can raise new possible solutions, but also help people feel included and informed
  • Next time we're together: group hug

Retro of this meeting:Edit

  • Good that we started with the basic premise
  • I feel like I got my story out
  • Walking away feeling good.
  • We talked about resolution points, so it would be good to see where those go
  • When Greg first got the pre-retro invite, thought: "Why talk about it before the discussion?"
    • But the pre-talk was useful for both Kevin and Greg (helped to voice ideas once before the real meeting)
    • ^ BG: I would've also liked a pre-talk, or at least clearer expectations (if possible) on what's going to come out of the meeting.
  • It's good to actually talk about areas of friction like this, rather than relying entirely on email/phab/IRC