[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Handling unblocks

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

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[1] and thus might
be considered noise in the release process.
Kind regards


[1] 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).


Reply to: