launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

Hi Robert,

First of all, let me emphasis that I'm thrilled to see this project
moving forward. Like I explained in my Dublin presentation, I really
hope this will bring the long-tail of our cycle distribution toward the
left.

Now, some things I'd like to get clarifications on...

On 11-07-12 08:39 PM, Robert Collins wrote:
> This mail is a little long, and there is a very important question in
> it, so the tl;dr version first:
> 
>  - if you know of a script we have, which if its database connection
> is interrupted requires manual fixup afterwards, please let stuart or
> I know.
> 
>  - For *all* new DB patches please aim for 10-15 second *total*
> application time on staging/qastaging. For assistance achieving that
> you're welcome to tap stuart or I. As of this week slow patches (> 15
> seconds) will require signoff by me or Francis, as they will cause
> custom excessive downtime.

Is this the total aggregated time of the pending patches? Or a maximum
of 10-15 second for one patch?

I also guess that this only applies to "apply-cold" patches? Since for
apply-live it either doesn't matter or disqualify them outright as
apply-live.

> 
>  - *no* more changes to both DB code and Python code at the same time:
> This applies to both devel and db-devel.

From the detailed portion of your email, I get that from now on,
"apply-cold" patches should still go onto db-devel.

Does this mean that we are introducing a two-weeks delay for any feature
that requires an apply-code patch until we can do fastdowntime reliably?
In other word, if I would be working on a change that requires a DB
patch, does it mean that:
- i write the patch
- land it on db-devel
- wait for it to be deploy (next full downtime or maybe fastdowntime)?
- write the python code that depends on the patch.

Or does it simply means that I have to use two landings?

- Write the DB patch
- Land it on db-devel
- QA the db patch on staging
- Write the python code
- Land it on db-devel
- QA the code on staging

That would means that to do fast downtime we would merge db-stable onto
devel up to the revision containing the DB changes, do the downtime and
deploy the patch. Then merge all revisons from db-stable afterwards that
don't introduce a patch, and do a nodowntime with them.

We should also stress out that this means that existing python code must
work with and without new DB patches?


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature