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). > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515ac682.1040...@pocock.com.au
