launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 11 October 2010 09:23:04 Jeroen Vermeulen wrote:
> >> 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.

Can you try and remember exactly what situation that was?  Nobody seems to 
remember yet this criticism is based on it.

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

From what you say here (please correct me if I misunderstand) it sounds to me 
like the problem was there before Michael started his changes and he had 
nothing to do with these problems?  And in fact it made you aware of the 
problem?

Regarding the hard testing - yes, I know, and I am trying to do something 
about that :)

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

While I fully support the idea of future Wellington-style sprints involving 
cross-team people & community, I'm not sure of the benefit of another one for 
buildfarm changes.  Can you be more specific about "revamp the model across 
the board" as I don't understand where the problem is.

Cheers
J