launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Fri, Dec 9, 2011 at 4:18 AM, Francis J. Lacoste
<francis.lacoste@xxxxxxxxxxxxx> wrote:
>> Wasn't that undone because it led ec2 to bless code that failed on buildbot?
>>
>
> It wasn't. I suggested we undo it, but Robert and Martin said that this
> only change the place where it's possible to make a mistake.
>
> If the same mistake happens again though, I'll personally disable it :-)

I think we need to reduce friction here; its true that this only
changes the place.

For clarity we have 5 places, managed separately, for package
dependencies issues to turn up before we deploy:
local dev, $ubuntu-tip + PPA
local dev, $LTS + PPA
ec2, $LTS + PPA
buildbot, $LTS + CAT
[qa]staging, $LTS + CAT

and then we deploy to production.

These are all updated in a fairly adhoc manner.

We want to end up with the following:
 - issues with production are avoided
 - spurious issues with staging/buildbot/ec2 are avoided
 - ditto developer issues

Manually updating ec2 means that ec2 skews from buildbot and [qa]staging when:
 - losa update buildbot or qastaging (which they do for security fixes
amongst other things) without coordinating with a developer
 - a developer updates ec2 and losa don't update at the same time

but has no impact on skew between [qa]staging/buildbot/developers -
all it ensures is that things that pass ec2 will pass buildbot *IF*
there is no skew.

I think a reasonable setup is for ec2 to autoupdate from the PPA,
buildbot to autoupdate from CAT, and folk to land packages to both the
PPA and CAT at the same time (otherwise we have dev box->ec2 skew).

-Rob