Re: Report from the Ruby Sprint, January 2014
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
Reply to: