-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was trying to practice QA'ing, and I ran into what seems like a process issue.
It seems overly difficult to QA launchpad changes that involve merge proposals. Is there something we can do to make it a bit easier? The specific bug is: https://bugs.launchpad.net/launchpad/+bug/436663 Which needs a merge proposal that is associated with a bug. I found: https://code.qastaging.launchpad.net/~gz/bzr/2.4_robust_logging_714449/+merge/84465 Which should fit the bill, but that particular merge proposal fails with an OOPS: https://oops.canonical.com/oops/?oopsid=OOPS-f2920da1f7b84040c094412e4d414bb8 That appears to be because it is trying to load the merge proposal diff from the librarian. My guess is that there is a different librarian for qastaging, but the database has all the identifiers from production. So I tried uploading a new branch (of launchpad, because I know we have lp://qastaging/launchpad as an actual branch). I then had webops run the branch scanner, but it failed with a timeout: https://pastebin.canonical.com/69133/ Note that trying to run the branch scanner again said "Nothing To Do" which indicates that we probably have found one of the bugs in scanning. (If it sees a new branch, but gets a timeout trying to process it, that branch does not get tried again later.) In the end, I could still create an empty merge proposal for that branch, and associate the bug I wanted, in order to QA the original bug. Possible things to do: 1) Get the branch scanner running regularly on qastaging, so we don't have to poke webops. This may be happening, as the merge-proposal job was already running at 5-min intervals. (Which is a bit slow for actual QA, but serviceable.) 2) Make sure timeouts on QAStaging are set up significantly from production. At least, as I understand it, we expect jobs/database access/etc to be a fair amount slower on QAStaging. Having to just reload a page until it loads doesn't seem like a great way to do it. (Note that I ran into probably 5 timeouts just loading regular pages that I had to reload to figure out if I was getting a real failure, or just a transient one.) 3) Have the qastaging librarian fall back to the regular librarian? Given that staging is a dump of production data, but we probably don't want to copy all the librarian content. I imagine we want a way to generate temporary librarian data, but fallback-to-production seems reasonable. Thoughts? John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/tfvcACgkQJdeBCYSNAAMZYwCeL9/TRFl84AL1ZFWiy1keI2NM COMAoMCA85DZU8Xuu6EwpH8aQMiawNQJ =NaMn -----END PGP 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
