launchpad-dev team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

> > I know that for both
> > Translations and Code, at one point they were *forced* to scramble and
> > update their part because that was required to fix some breakage. Sorry,
> > to be hand-wavy around the precise breakage that required completing that
> > refactoring, but if you are interested, I'm sure Danilo, and Aaron or Tim
> > can fill in the details.
I too forget the details but I don't feel the Translations team were 
forced by anyone in particular to scramble and update our code.  However 
we did end up in a situation where we had to do so.
While I agree completely with what Francis advocates, I find no fault 
with how this particular change was broadcast.  We got persistent 
reminders from outside the team and there was constant awareness within 
the team that we needed to move to the new model soon.  There just 
happened to be enough pressure in other areas to keep us busy.

> Michael went to great lengths to ensure that his work was backwardly
> compatible and that nobody was forced to do anything, and from my point of
> view I thought he did an incredible job.  Not only did he come up with
> fantastic code, it worked first time in production, and didn't break the Code
> and Translations jobs.
Yes and no.  As we now know, the compabitility provisions were masking a 
flaw: the bridge between the old and the new models was built on the 
very part of the old design that never applied to Translations in the 
first place--one of the very problems the new model fixes.  We're lucky 
to have caught this even now, given how hard some of the buildfarm stuff 
is to test; we could have ended up with our jobs being quietly ignored 
for unclear reasons.  We know how to get back on track, but that 
involves a change of plans for the model migration itself.
What can we do better in a situation like this?  The job is too big to 
expect one or two people to go all the way in one haul.  A feature 
branch alone won't cut it at this scale of change.  Keeping affected 
teams in the loop didn't work out--for reasons that would be interesting 
to discuss separately, but for now I'll just say they are the problems 
you get with virtual teams and long-term goals.
What I think would work best here is to bring the virtual team back 
together for a "Wellington II: Return to the Buildfarm" sprint, to 
revamp the model across the board and meet Q/A criteria worked out in 
advance.  Make the team non-virtual, bring the goals to the short term, 
go back to our "regular" work when done.

Jeroen