Bug#596574: unblock: ruby1.9.1/1.9.2.0-1 libgems-ruby/1.3.7-2
On 16/09/10 at 13:26 +0100, Adam D. Barratt wrote:
> On Mon, September 13, 2010 14:42, Adam D. Barratt wrote:
> > On Mon, September 13, 2010 14:12, Lucas Nussbaum wrote:
> >> On 13/09/10 at 13:19 +0100, Adam D. Barratt wrote:
> >>> On Sun, September 12, 2010 18:27, Lucas Nussbaum wrote:
>
> libgems-ruby has been unblocked but can't migrate until ruby1.9.1 does;
> which brings us back to...
>
> >>> > Then, ruby1.9.1 1.9.2.0-1.
> >>>
> >>> Already unblocked by Luk as part of the "security fixes unblock" set,
> >>> but aged to 20 days.
> >>
> >> I don't understand the reason for that. I think that we agree that this
> >> version is better than the previous one. Why do you prefer to reduce the
> >> opportunity for testing by not letting it migrate now?
> >
> > I assume that was "plural you". :)
> >
> > From <[🔎] 4C8DBE97.60701@debian.org>:
> >
> > /=============================
> > | > unblock ruby1.9.1/1.9.2.0-1
> > |
> > | unblocked and aged to 20 days due to massive changes
> > \=============================
> >
> > From a quick look at the diff, much of the changes appear to be
> > auto-generated stuff in enc/trans/ and ext/ripper; are either/both of
> > those used in the packages?
I assume they are, though I haven't analyzed the upstream build process
to confirm that. The huge diff to those files is also contained in the
upstream tarball.
I don't think that size(change) is correlated with risk(change), so I
don't really see the point of this discussion.
- Lucas
Reply to: