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.laco...@canonical.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
