Comment 20 for bug 548824

Revision history for this message
Graham Binns (gmb) wrote : Re: createBug should take an optional blob ticket

Okay, so after reading the entire comment thread and then reading it again because I got confused, here's how I understand where we stand at the moment. Please correct any mistakes.

 1. We've added a method, getProcessedData(), to ITemporaryBlobStorage. This returns a dict containing the data that has been parsed from an uploaded Apport blob (i.e. the same data that the +filebug process uses to populate new bugs).
 2. The Launchpad test suite covers the correct parsing of Apport blobs (see http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/lib/lp/bugs/tests/test_apportjob.py)
 3. The LP test suite covers using the data from an Apport blob in the +filebug process (see http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/lib/lp/bugs/stories/guided-filebug/xx-bug-reporting-tools.txt)

Now, AIUI the use-case for this bug is the Apport test suite. Since it's been said above that Launchpad's own test coverage of blob parsing (assuming it's complete enough) is sufficient for the case of testing "apport uploads stuff and Launchpad inserts it in the bug appropriately, I'm not quite clear on why we still need to add a blob_id parameter to createBug(). Is there some test in the apport suite that requires an actual Bug to exist on the Launchpad side? At the moment it seems like we're heading for test duplication by actually creating a Bug in the Apport test suite. Especially since Apport never actually files bugs itself in real usage; it uploads the data and lets the user complete the report.

So, as I read it, I think we've solved the use-case for this bug, providing that we're happy that the LP test suite is comprehensive enough in its testing blobs being parsed and injected into the +filebug process. However, I admit to being a bit confused at this point, so feel free to tell me why I'm wrong.