launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #05101
Re: Going all the way or the proper way to create work for others
Hi folks,
On Friday 08 October 2010 14:45:58 Francis J. Lacoste 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
I'm pretty sure this was done as well as it could be. We consistently told
the Code and Translations teams that they would need to schedule the work as
soon as convenient. Although not strictly mandatory, it was highly desirable
from a buildd admin point of view.
As Michael already pointed out, the redesign was discussed with all the
involved parties. Once the new API was finalised Michael arranged to discuss
it with them in more detail.
> 2- and from my understanding, it's not accurate to say that Soyuz was
> updated without affecting the other areas.
I think you've misunderstood Francis, this not the case.
> 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.
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.
At no point were the Translations and Code teams forced to scramble as a
direct result of this change, so I suspect you might be thinking of something
else that caused this?
Cheers,
J.
> 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
>
> > 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
Follow ups
References