Comment 7 for bug 876594

I'm back to working on this, but still lost in building a scenario we could use for an acceptance test.

We do know that the actual error message comes out of verifyFormat. Here's the call stack, as far as I can reconstruct:

BaseBinaryUploadFile.verifyFormat
 ← BaseBinaryUploadFile.verify (e.g. for a DebBinaryUploadFile)
   ← DSCFile.checkFiles (calls on DSCUploadedFile, child of NascentUploadFile)
     ← DSCFile.verify
       ← NascentUpload.process
         ← {Build,User}UploadHandler._processUpload
           ← UploadHandler.processChangesFile
             ← {Build,User}UploadHandler.process
               ← UploadProcessor.processUploadQueue
                 ← ProcessUpload.main

The call to notify() that we want to catch probably originates somewhere in NascentUpload.process or {Build,User}UploadHandler._processUpload. Unfortunately there are many code paths that can end up calling notify().

That's control flow. But we also have data flow to worry about: as I understand it, the source package release gets synced from Debian into Ubuntu. That triggers builds for the appropriate architectures, resulting in binary uploads, which is where the error happens.

It looks like we can tell that notifying the maintainer is inappropriate if the upload's target archive is a different one than the source package release. Here's what we decided… Compare BinaryPackageBuild archive to target archive: if different, do not notify addressees from changes file (maintainer, changed-by).