Re: Handling unblocks
On 02/04/13 09:24, Andreas Tille wrote:
> [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.
>
Absolute size of a diff isn't everything. Sure a 1 line diff against a
100 line script is easy to compare. A 1000 line diff against a
1,000,000 line source tree may really only contain essential and highly
desirable fixes, and is only 0.1% of the code (compared to the 1% change
of the 1 line diff).
This freeze process is all about testing, and if people do test their
packages in the now relatively stable world of wheezy and they find some
remaining bugs and make fixes, then there is a good chance that those
fixes are worth delivering.
The problem is, how to pass this benefit on to users without either (a)
marking every bug RC or (b) asking the release team to review more code
than humanly possible?
One idea that comes to mind is to make it easier for other developers to
screen unblock requests against the packages they depend on or use
regularly. Would this workflow be feasible? E.g. a utility that runs on
my desktop, detects what binaries I use, and cross references that
against unblock requests and asks me to comment on them?
To put this in context, I recently found that one of the packages I
depend on (libasio-dev) is actually orphaned. It is mentioned in PTS,
but I was never proactively alerted by anything such as lintian. There
are probably many cases like this (orphaned library, unblock request)
where users of a package are likely to be interested in helping out.
Another area for efficiency may be to accredit packages for express
unblock processing. Most of my upstream projects have stable release
branches and where I act as upstream release manager, I aim to only
include things on a release branch that are not going to break
anything. In other words, the releases from those branches would all be
safe to send into the stable archive. Not all upstreams work this way,
some don't even have release branches, but for those that do, the
release team may not need to look at their unblock requests so closely.
> Kind regards
>
> Andreas.
>
> [1] If you might wonder what other problems than RC bugs should be
> handled by unblock requests I wrote a mail
> http://lists.debian.org/debian-release/2012/06/msg00323.html
> 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
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702722#10
>
> 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: