On Fri, Dec 9, 2011 at 4:18 AM, Francis J. Lacoste <francis.laco...@canonical.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
