Re: Handling unblocks
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
Reply to: