Re: Bits from the Ruby team: switching to Ruby 1.9 and trasition to new policy
On 08/06/12 at 20:06 +0100, Adam D. Barratt wrote:
> On Mon, 2012-06-04 at 23:40 +0200, Lucas Nussbaum wrote:
> > On 04/06/12 at 19:59 +0100, Adam D. Barratt wrote:
> > But now, the last step is to switch to 1.9.x as default, instead of 1.8.
> > Yes, it's late in the release cycle. But:
> > (0) the switch to 1.9.x as default Ruby is very important for us, since
> > it is the final achievement of most of the work done during that
> > cycle
> > (1) we are not frozen yet
>
> That's somewhat of a self-fulfilling statement. Unless we take the
> decision to freeze knowing that some changes aren't complete, then
> adding more larger-scale changes affects our ability to freeze (and
> certainly our ability to release). (That's not a statement either way
> about the specifics of the wheezy freeze, fwiw...)
(Not specifically about Ruby, but ... )
You seem to think that DD will moderate themselves and stop pushing
large-scale changes since the freeze is approaching, thus increasing
the ability to freeze. I think that the opposite happens: with the
freeze approaching, people hurry to push large-scale changes, without
all the QA they should have gone through.
I think that the only way to freeze is to freeze. Just freeze during
June as planned, to block all large-scale changes. And then we can spend
time fixing RC bugs and cleaning up the large-scale changes that went
through before the freeze. Sure, it will be painful, but it won't be
worse than delaying the freeze (and let other large-scale changes can
get through).
Having been active in QA in >5 years, I know that the way we handled
this Ruby transition is not perfect, but it's the best we could do given
the timeline and the manpower we had. Also, I believe that it's
important for Debian (at least for Ruby in Debian) to move to 1.9 as
default for wheezy, rather than stay behind with 1.8.
> On Tue, 2012-06-05 at 00:42 +0200, Lucas Nussbaum wrote:
> > I've tagged new FTBFS that could be linked to Ruby 1.9.x:
> >
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default19;users=debian-ruby@lists.debian.org
> >
> > There might be some more: I need to rebuild the packages that were
> > failing due to the gem2deb bug that I fixed earlier tonight.
>
> Should the list above now be reasonably complete? It looks like there's
> currently around 50 unresolved bugs, although I admit I haven't checked
> the detail of each report.
There are basically two kind of bugs related to this transition:
(B1) The package build system breaks because 1.9 is the default
(B2) The software is not compatible with 1.9
All the bugs about (B1) have been filed and tagged. I don't expect them
to be very hard to fix.
Regarding (B2), we need a way to detect the problem. When packaging with
gem2deb, maintainers are deeply encouraged to run test suites during
build. In that case, bugs have been filed too. But then, we have the
packages that silently broke due to 1.9 as default. We will only know
about them when users report bugs. Those can be fixed (or worked-around)
by disabling 1.9 support for those applications or libs.
All in all, yes, that's a lot of bugs. But none of them should be very
hard to fix. If you have bugs that require a quick fix through a NMU due
to a current transition, don't hesite to ping #debian-ruby or
debian-ruby@lists.debian.org.
Lucas
Reply to: