← Back to team overview

launchpad-dev team mailing list archive

Hard to QA Merge Proposal changes


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:

Which needs a merge proposal that is associated with a bug. I found:

Which should fit the bill, but that particular merge proposal fails
with an OOPS:

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

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:

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

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/