launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

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