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
--
Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: Digital signature