launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Fri, Oct 8, 2010 at 3:45 PM, Francis J. Lacoste
<francis.lacoste@xxxxxxxxxxxxx> wrote:
> Hi Michael,
>
> In the build record history case, I think there were two aspects:
>
> 1- Like you point out, communication around the hand off came a little late
>
> 2- and from my understanding, it's not accurate to say that Soyuz was updated
> without affecting the other areas. 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.

Yeah - I am. I've certainly forgotten what that was...and I am keen to
remember? The only breakage I can remember is when the separate
build-from-branch code was landing at the same time as the soyuz
refactoring work - and a piece that I landed caused a conflict with
the build-from-branch work (updateStatus_OK or similar, which I worked
together with Aaron to fix). But that wasn't related to the Code team
updating their part of the build refactoring. And I'm not aware either
why the translations team was forced to drop things when we landed the
soyuz refactoring. I was under the impression that when the soyuz
change landed, the rollout went quite smoothly (without affecting
other teams).

As I understood it, both Aaron did their build refactoring work at a
later point... so I'm not sure why they had to drop everything to do
it. The only implication, aiui, was that they wouldn't benefit from
seeing their new build types in the builder histories until their
relevant part of the refactoring was done.

I'm not trying to avoid responsibility - and I've already learned lots
through the experience, but I am keen to understand why other
teams/developers feel they were forced to drop things when we worked
hard to ensure the soyuz part was updated without disturbing them.

Cheers,
M
>
> To reiterate, it's ok, although not ideal, when a large change requires a
> hands off to the other teams. But it's very important that this hand off
> doesn't mean that other team have to disrupt their schedule to take it.
>
> Cheers
>
> --
> Francis J. Lacoste
> francis.lacoste@xxxxxxxxxxxxx
>
> On October 8, 2010, Michael Nelson wrote:
>> On Wed, Oct 6, 2010 at 8:05 PM, Francis J. Lacoste
>>
>> <francis.lacoste@xxxxxxxxxxxxx> wrote:
>> > For illustration purpose only, two recent examples of rippled changes
>> > that should happen differently next time:
>> >
>> > - New way to handle OOPS in cron scripts
>> > - Refactoring of the build record history
>>
>> Similarly, for my/our own learning, I'd be keen to know other ways we
>> could have improved this process for the build refactoring. We tried
>> to involve everyone in the refactor design (both canonical and
>> community), got agreement before implementing and updated the soyuz
>> component to the new model without affecting other areas.
>>
>> FWIW, I had planned to go all the way and also update code and
>> translations to the new models also, but was not able to (having to
>> move onto other soyuz priorities). As soon as I was aware of this I
>> tried to make sure code/translations were aware of what would need to
>> be done when they had time (sitting with both Aaron and Jeroen in
>> Prague to work through examples). I'm sure communication wasn't
>> perfect (and never will be), but I'd be keen to know how we could have
>> improved our communication of the changes.
>>
>> Thanks!
>> Michael
>