annoyed how SRU's are currently handled

[Matthias Klose]

Hi,

with the latest rejection of gcc-4.6 for precise-proposed, my motivation to
contribute to stable release updates is below zero.  For this particular upload

 - I got a reject message without any reason, and had to figure out with
   help from Colin from irc logs who did reject the upload.  No, even on
   irc no reason was given.

 - Talking with Steve, he pointed out that one issue actually has some
   information in the wrong place, although afaics there is no information
   missing.

The worst thing about this is that nothing can be traced. Good luck for you if
you are online, but if you are not, you are on your own figuring out the
reasons.  Please compare this with other processes like the MIR process where
everything is documented in a bug report, with removal of packages (again,
documented in bug reports), or package rejections from the NEW queue, where
package maintainers send an email to the uploader and ubuntu-archive.

Another thing is the pedantic attitude that everything to reproduce the issue
has to be in the bug description. Looking at #972648, this information
actually is even included partially in the bug description (the gcc command
line).  Pasting the preprocessed source in the bug description seems to be wrong.

And last but not least, not only with this issue, the SRU processing is not the
fastest. Yes, there are delays in MIR handling as well, but usually these get
addressed faster, and because these can't be delayed infinitely the MIR team
usually tries to handle missing and incomplete information in a cooperative way.
I would like to see a similar attitude from the SRU team.

It is good to have stricter requirements for SRU's than for normal uploads, but
imo it's wrong to have these requirements to just discourage SRU's.

  Matthias