launchpad-dev team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

On 2010-10-11 16:21, Julian Edwards wrote:

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

I have a vague recollection of Q/A turning up something we wanted or had 
to resolve before rollout.  It may or may not have been an aspect of the 
"no bridge between old and new" problem.  We should have done the 
conversion earlier, and if we'd had time we would have.  But frankly I 
don't think it matters here: hindsight of a problem is not the same as 
criticism.


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

I don't know when the problem "was there" all of a sudden.  I would say 
that it must have happened in the phasing of the migration: the new 
model doesn't need the old Build objects, and it's well known that 
Translations never had them, but they were required in an intermediate 
phase that the plan assumed Translations could migrate to before work 
could proceed.


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

I meant across the board to be along two axes: across all job types, but 
also all the way to the new model with fewer intermediate "stable 
points" where we need to plan for deploying code that's migrated only 
part of the way.

As for the benefits of a sprint, consider:

 * The intermediate phase we failed to achieve turned out not to be a 
stable point at all.  At a sprint we can march straight through unstable 
phases and commit to meet up on the other end--as we did in Wellington.

 * Our attempt to catch up exposed the problem.  At a sprint we 
wouldn't have fallen so far out of step.  I would have asked how to 
solve this for the Translations jobs and we would soon have seen what 
was wrong.

 * Several people had to go through the exact same steps of discussing 
the problem on IRC, coming up with the same solutions, and finding out 
why they wouldn't work.  With everyone in the same room we could have 
gone straight to brass tacks.

 * Support for the intermediate phases adds a lot of complexity.  No 
wonder we sometimes miss something.  We would have found it easier 
standing around a whiteboard.

 * Other work distracts us.  This stuff needs focus.

I can't say with certainty that we'll hit more problems of this sort.  A 
sprint _may_ not pay off.  But this is a lot of 
if-only-we'd-been-sprinting for just one.  Plus, I think getting a clean 
new model done quickly would be well worth it.


Jeroen