annoyed how SRU's are currently handled

[Clint Byrum]

Excerpts from Matthias Klose's message of 2013-03-14 15:00:19 -0700:
> 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.
> 

Whoever rejected the upload should have emailed you directly if you were
listed in the changelog. There's an open bug request for launchpad to have
a way to enter a reject reason that would be automatically emailed. But
for now, whoever did that, did it wrong IMO.

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

So, how many developers are there, vs. SRU team members? Is it so much
to ask that developers who are uploading to the SRU team's review queue
have things arranged properly so we can find it easily and don't have to
dig? This goes for SRU bug verifiers too, they should be able to look
at the bug description and see how to reproduce, and what areas of a
program need testing because of regression risks.

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

In what way have we, the SRU team, not been cooperative? There is a very
clear wiki page with the process to follow. When it is not followed, we do
not reject uploads immediately, but ask that it please be followed. Once
it has been followed, the uploads get processed.

Some of us are just volunteers these days, so we don't have much time. I
suspect that the backup of SRU's is one reason for the rolling release
discussion. With less supported releases and/or packages, the SRU team
could narrow its focus.

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

I'm sorry that you're discouraged Matthias, but unless there are more
people available to review SRU's, or more software is put through the
MRE process, I don't think there's much more we can do and still maintain
a level of stability in the stable releases.