my [assign your pricetag]: Thank you guys for all your hard work, and thank you Antonio for the report!
Cheers! On Fri, 07 Feb 2014, Antonio Terceiro wrote: > This is the report of the Ruby team sprint that was held at the IRILL > offices in Paris, France betwen January 15th and 17th, 2014. We thank > IRILL for hosting us, and the Debian sponsors for funding the expenses > required for the sprint. > # Attendees > * Antonio Terceiro > * Cédric Boutillier > * Christian Hofstaedtler > * Jonas Genannt > * Lucas Nussbaum (Jan 17th) > # Initial plans > The following topics were worked on: > - Work towards removal of Ruby 1.8 > - Decide on supported interpreter versions for Jessie > - Get the Rails 3 package(s) in shape > - Get the Rails 4 packages(3) in shape > - Discussion of an initial list of key packages for the team > - Drop the standalone `rubygems` package > - Work on removal of old transitional packages remaining from the wheezy > changes (~100) > - Support for autopkgtest in gem2deb > - Ruby policy and the ruby-policy package > We were able to work on all but the last two items. The results are > reported below. Raw notes (unreviewed) that were taken during the sprint > can be found at http://www.okfnpad.org/p/DebianRubySprintParis2014 > In general, the sprint was very productive and fun, and we encourage other > teams that did not have one yet (as was the case of the Ruby team) to try it > out! Some things really are best discussed in a room with a whiteboard. In our > case, working out the plan forward with regard to obsolete and new Ruby > interpreters would probably have taken us weeks over email, but we were able > to > settle on a good enough solution in one afternoon. > # Work towards removal of Ruby 1.8 > Work in this area mainly involves either fixing packages to work with a > newer Ruby version, or giving up because the package is broken beyond > repair, in which case we file removal bugs for them. Pretty much all of > the packages in the second case have long-dead upstream and nobody > caring about them out there. > In this front, we did: > - ~24 uploads fixing packages > - ~9 patches sent to the BTS > - ~29 bugs filed and/or updated > # Decision on interpreter versions > Taking the upstream support periods into account: > This discussion started by us collecting the expected EOL dates for the > currently Ruby series supported by upstream: > Version Release Date Upstream EOL > ======= ============= ============ > 1.8 irrelevant Past EOL > 1.9.3 irrelevant Feb 2015¹ > 2.0.0 Feb 2013 Feb 2016 (best case)² > 2.1 Dec 2013 Dec 2016 (best case)² > 2.2 Dec 2015 (?) Dec 2018 (best case)² > ¹ http://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will-end-on-2015/ > ² https://bugs.ruby-lang.org/issues/9215#change-43556 > Assuming that Jessie will freeze early November of 2014, (optimistically one > could say) estimating its release for June 2015, and assuming 3 years of > support, the EOL for Jessie would be June 2018. With these dates in mind: > - It's impractical to keep Ruby 1.9 for Jessie > - Ruby 2.2 will be released too late to be considered for Jessie > It's clear to us that the default should be 2.1. > The remaining question would be whether it's worthwhile to also keep > 2.0, and we thought "it's not". The more recent Ruby versions have not > been introducing as much backwards incompability as it was the case for > Ruby 1.9 wrt to Ruby 1.8. So if any Ruby project works today with Ruby > 1.9 (the oldest of the upstream-supported series), it will most likely > also work with either Ruby 2.0 and Ruby 2.1. > This led us to the realization that because of this, it does not make > much sense for us to keep supporting multiple Ruby versions > simultaneously. > Having multiple interpreters is a burden: > - on the interpreter maintainer(s), who have to maintain multiple > versions for multiple debian versions. A single security issue might > need 6+ separate uploads (2+ ruby versions x 3 suites - unstable, > stable, oldstable) that have to be built and tested. > - on the Ruby team, since whenever we want o drop a old and deprecated > interpreter we have to hunt down every maintainer to have their > packages updated so we can remove the old interpreter. > - because of the alternatives choice, upgrades might be a pain if users > have explicitly selected an old interpreter as /usr/bin/ruby. > Moving forward, our plan is to have a single Ruby interpreter in the > archive. We will keep the infrastructure for multiple versions around so > that we can have multiple versions simultaneously on a temporary basis > when we want to introduce a new version with a smoother transition. > So the next months you can expect that: > - ruby1.8 will be removed > - ruby1.9.1 will be removed > - ruby2.0 will be made the default (pretty soon) > - ruby2.1 will be made the default (later) > - ruby2.0 will be removed > - switching /usr/bin/ruby with update-alternatives will be no longer > supported > # Get the Rails 3 package(s) in shape > - finished and uploaded unified rails 3 source package (rails-3.2), to > replace ~8 separate source packages. The new package includes an > autopkgtest test suite that will alert us if any dependency breaks > Rails. Currently waiting in NEW. > - fixed and uploaded rubygems-integration to make it work properly with > ruby2.0 > # Get the Rails 4 package(s) in shape > - Fixed ruby-sprockets, ruby-sprockets-rails to become installable again > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732992 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732995) > - Uploaded ruby-thor git version, to fix bundler 1.5.1 > - Upload bundler 1.5.2 > - Relaxed Rails dependencies on tzinfo, builder so that Debian > package relationships match Rubygems relationships > - Debugged bundler, resulting in a Debian-revert of the upstream commit > in question https://github.com/bundler/bundler/issues/2818 > - Reintroduce patch from Rails 3.2 into 4: > be-careful-with-that-bundler.patch > - Recorded required additional work on Rails 4: > - Packages that need to be put into rails Recommends, at the very least: > ruby-sqlite3, ruby-activerecord-deprecated-finders, ruby-builder, > ruby-tzinfo > - Package sdoc (started, might be easier when Ruby 1.9 is gone) > - Need a lot more gems packaged > # Discussion of an initial list of key packages for the team > We discussed whether it made sense to create a list of `key packages` > for the team, which the team collective will make sure are kept in a > good shape. We concluded that it didn't make much sense to create such > an explicit list, and let people take care of the package that they care > about, since the few packages we could think as being 'key' (rake, > bundler, rails, etc) already had people who take care of them. > # Drop the standalone `rubygems` package > Starting from Ruby 1.9, the Rubygems package manage is shipped together with > the interpreter. So we have to do some work to be able to remove the > standalone > rubygems package. For this, 8 packages were uploaded dropping (unnecessary) > dependencies on `rubygems`. > Since the end of the sprint this work has been completed, an RM bug (#735576) > has been opened for rubygems, and it was removed from unstable on January > 31st. > # Work on removal of old transitional packages remaining from the wheezy > # changes > 52 bugs were filed to have source packages drop old lib*-ruby* binary > packages in favor of ruby-* ones: > http://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=ruby-policy-remove-transitional-packages&user=jonas.genannt%40capi2name.de > Additionally, several of the team packages were uploaded making the > necessary changes -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
