Wikimedia Apps/Team/Retrospectives/Retrospective-iOS-Github-2015-08-03
Appearance
iOS Github Retrospective
[edit]- 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.
Discussion
[edit]- 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