Hi Adam, On Tue, Apr 02, 2013 at 01:32:50PM +0100, Adam D. Barratt wrote: > On 02.04.2013 08:24, Andreas Tille wrote: > >The only thing I'm wondering about is: Will all unblock requests be > >handled before the release (either by an unblock or a refusal)? > > That's the plan, yes. As Neil said, we've unfortunately not been as > good as we should have been at saying "no" (we don't like doing it, > but sometimes avoiding it causes bigger issues).
That's perfectly fine. > [...] > > 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). > > That sounds like you're suggesting raising the severity of non-RC > bugs to RC levels just so that they're "on the radar". This was not a suggestion but rather a question (typographically missing the question mark) and the intention of my question was to find out whether you (in terms of the release team) would regard this helpful or not. > Whilst that > would indeed be the effect, it would be an abuse of the severity > levels and I'd expect the result to be a quick revert back to a > lower level and less inclination to look at the issue (whether the > latter should be the case is another matter, but at the end of the > day we're still people and it could be difficult to avoid such a > reaction). As I said in the end I would not consider such means if all unblock requests will be handled - so everything is fine. > I have to admit I'm still a little confused as to why these updates > couldn't have been done before the freeze in any case. Recently there was an example which might prove my point: $ LANG= apt-cache policy freecad freecad: Installed: (none) Candidate: 0.12.5284-dfsg-7 Version table: 0.13~20121120.git5082ae2-2~exp2 0 5 http://ftp2.de.debian.org/debian/ experimental/main amd64 Packages 0.12.5284-dfsg-7 0 50 http://ftp2.de.debian.org/debian/ unstable/main amd64 Packages $ apt-cache rdepends freecad freecad Reverse Depends: freecad-doc freecad-dev freecad-dev science-engineering Freecad was just removed from testing (#617613) but it is in the list of dependencies of the science-engineering metapackage. So the set of debian-science metapackages needs to be recreated, uploaded and unblocked to enable a consistent set of dependencies in testing. This can happen until the end of the release process (or as long as there are RC bugs in the set of a Blends dependencies). Very strictly speaking we could for sure now file an RC bug against debian-science package and run this circle for each removed or added dependency but we avoided this in past releases but rather created the metapackages in the end of a release process. As far as I can see freecad was the last candidate with potentially "bad" outcome for the release and so I'm about to recreate debian-science metapackages now. I also uploaded debian-gis because spatialite-bin seems to be "safe" in testing (but was not some weeks ago when I checked last time). Hope this does clarify the problem and thanks for the hard work and withstand the harsh wind here on the list Andreas. -- http://fam-tille.de -- 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/20130402132801.gm25...@an3as.eu
