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

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
  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
Reverse Depends:

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



Reply to: