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-r...@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-r...@lists.debian.org. Lucas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120609001814.ga3...@xanadu.blop.info