Once something lands in trunk (devel *or* db-devel), its in a critical section: until its deployability has been assessed, we /cannot/ deploy past it and thus our development pipeline halts.
Checking the deployability of code in our pipeline is less important than dealing with an emergency (e.g. service down) but more important than writing new code etc. Often the person that made a change will be best placed to assess things, so there is a reasonable bias to let the person that landed something do the QA; however this is a team responsibility with team impact if we fail at it. I'll see what ones I can QA; any that are *not* qa-ok come Monday morning will /not/ be in the DB downtime deploy on Wednesday. The db-stable report is at : https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html. Just like the The db-stable report is at : https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html report, you should look at this ~12 (*) hours after sending a change to EC2 (4-5 hours in EC2, 4-5 + up to 4-5 for the run before to complete in buildbot, then 2 hours to deploy on staging). I've CC'd the folk that landed the un-qa'd changes: if I don't manage to figure out how to QA these things, your help /will/ be needed. Cheers, Rob (*): this delay has a huge impact on context switches, I know; this stuff is hard - and thats why contributing factors like test performance are in the pipeline to be fixed :) _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
