On Thu, Jul 14, 2011 at 4:45 AM, Francis J. Lacoste <francis.laco...@canonical.com> wrote: > 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.
Me too :) We need socialist distributions! > 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? For a single patch; and we're only going to ever apply a single patch at a time. > 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. Right. >> >> - *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. The latter for now; 2 landings. As we get more sophisticated I hope we can delete db-devel entirely. > We should also stress out that this means that existing python code must > work with and without new DB patches? Absolutely. -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
