]] "Adam D. Barratt" > > (please Cc me on replies, I'm not subscribed to the list) > > Done, although I had to override the M-F-T...
thanks and my apologies. Seems like my automation got the best of me. > >> On Thu, 2012-07-05 at 08:51 -0300, Antonio Terceiro wrote: > >> > If we can't get the fixed ruby-fast-xs in wheezy, then the > >> existing > >> > version of ruby-hpricot in wheezy will be fine, but we won't have > >> > chef-expander, which is an important piece in large-scale Debian > >> > deployments with chef. > >> > >> Thanks for the explanation. If it's such an important part though, > >> it's > >> slightly surprising that there were no uploads to Debian (not even > >> to > >> experimental) until the day before the freeze. :-( > > > > It's been developed and maintained in an upstream apt repository and > > while I was in touch with them some years ago about getting it into > > Debian, the effort was only seriously started early this summer. > > Upstream has been doing packaging in their own repository for quite > > some > > time (as can be evidenced by the changelog). > > Are they expecting to carry on doing that, or for everyone currently > using their packages to switch wholesale over to using the packages > from the Debian archive? I believe the 10.12 packages in Debian will be considered supported and «golden» until we release wheezy+1. For anybody who wants newer features, the upstream archive will still be provided. While we haven't explicitly agreed on this, I expect to continue syncing Debian and the upstream archive for the foreseeable future. If this has any impact on the decision whether to allow ruby-fast-xs (and for me more interestingly: chef-expander) into wheezy, I can get a more firm commitment from Opscode. > > They are at least in part based on chef's upstream packaging of > > same. And, they're scheduled to go in today anyway, so the only > > difference to whether ruby-fast-xs 0.8.0-3 is approved or not is > > whether > > that version plus chef-expander goes in, not the rest of the ruby > > packages. > > Fair point. It's still somewhat stretching the edges of the unblock > criteria though, given that chef-expander's exception is based purely > on the grounds of it being in unstable at the right time (with, as you > know, some debate as to whether NEW packages should have been granted > an exception even then) and the bug in ruby-hpricot doesn't affect the > version of the package in wheezy. Agreed on the stretching part. As for the bug in ruby-hpricot not affecting the package in wheezy, that's debatable, given the package in wheezy has an undeclared conflict with another package in the archive. (Please forgive me if I'm splitting hairs here, but I don't think the criteria has been «in the same suite» in the past, but rather whether it's got an undeclared conflict with any package in the archive. (Not that this helps, given what I want to get transitioned is ruby-fast-xs, though. :-)) On the other hand, I think that not providing chef-expander (but the rest of the chef server stack) in wheezy is providing our users with an inferior experience compared to what I think we can offer them. I'm not sure if there's anything I can reasonably offer you that'll make you more happy to accept the unblock (three RC bug fixes? ;-), but if there is, please tell me and I'll see what I can get done. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87obnnnrt3....@xoog.err.no
