launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

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 :)