launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Nov 3, 2010 at 3:04 AM, Francis J. Lacoste
<francis.lacoste@xxxxxxxxxxxxx> wrote:
>> This will have the following impact:
>>  - we'll see a clean db upgrade happen with all the db patches
>
> Is that because we are going to run the upgrade on qastaging? Can we handle
> this yet?

"Small matter of code" - I'm sure that its not precanned, but we do it
for staging all the time. Should be pretty straight forward to handle
it for qastaging once a month.

> I'm not sure it's that different that what we have now, as we do see the clean
> db upgrade happen with all the db patches on staging on the Saturday. I can
> see that if the db upgrade is made on qastaging on Friday, it is marginally
> better since it doesn't happen over the week-end. But it will do it with a
> database lagged way more than staging full restore.

the data lag is measured in days, the depth of history in the DB [for
most features] is measured in years : I don't think it makes much
difference.

>>  - code will converge faster (because we don't wait for the release to
>> have db-devel merged to devel)
>>  - revnos in production will not jump around
>>
>
> The only issue you missed out is that as soon as we merge db-devel to devel,
> we lose our ability to deploy fixes to production without a cow-boy. I think
> that may be still a problem (it's required often enough to not be dismissed.)

Thats true. OTOH we use cowboys for all urgent fixes *anyway* (this is
by observation, not policy or edict). We're aiming to get all blocking
sections down to a period of hours rather than days, but thats still
much longer than really-critical-things-are-willing-to-wait.

-Rob