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 -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
