[moving to debian-devel as Neil suggested]
On Mon, Apr 01, 2013 at 04:52:30PM +0100, Neil McGovern wrote:
> As a general hint, requests that are "obviously correct" get approved
> very quicky.
I can confirm this - thanks for the release team.
> Things that are "obviously wrong" get rejected very
> quickly. The problem happens when there's something in between.
Thanks for the explanation.
> The problem is that we keep looking at them, going "urgh" and moving on
> to something else easier. This will particularly happen if it's a huge
Very reasonable workflow.
> This isn't to excuse not rejecting things if there's little chance of us
> actually reviewing them, but may be useful background info into the
> thoughts of the release team when dealing with unblocks.
The only thing I'm wondering about is: Will all unblock requests be
handled before the release (either by an unblock or a refusal)? I'm
asking because I'm wondering if in the large set of unblocks some issues
might be hidden if not actually connected to RC bugs and thus might
be considered noise in the release process.
 If you might wonder what other problems than RC bugs should be
handled by unblock requests I wrote a mail
to explain why Blends metapackages need to be created at the
*end* of the release process to make sure all dependencies will
be really fullfilled. The actual unblock for
contained a remark from release team that makes me wonder whether
this was regarded as reasonable. If similar bugs (need to upload
debian-gis and debian-science, debian-med is uploaded #696387)
might be delayed (which I perfectly understand) is it possibly a
good idea to increase the severity of these bugs to make sure
that they will be handled before the release. I would not
consider this if you confirm that all unblocks will be really
handled (in whatever way as said above).