|Deletions are marked like this.||Additions are marked like this.|
|Line 13:||Line 13:|
|== pkg-ruby ==||== pkg-ruby (interpreters) ==|
|Line 15:||Line 15:|
|* Packages are maintained in git using collab-maint. See PTS pages for [[http://packages.qa.debian.org/r/ruby1.8.html ruby1.8]] and [[http://packages.qa.debian.org/r/ruby1.9.1.html ruby1.9.1]].||* Packages are maintained in git using collab-maint. See PTS pages for [[http://packages.qa.debian.org/r/ruby1.8.html|ruby1.8]] and [[http://packages.qa.debian.org/r/ruby1.9.1.html|ruby1.9.1]].|
|Line 18:||Line 18:|
|* <<Icon(star_on.png)>> Subscribe to the pkg-ruby packages (ruby1.8, ruby1.9.1, ruby-defaults) on the Packages Tracking System, and then contribute to the bug mail you get. (It is a good idea to also subscribe to bugmail from Ubuntu, see [[http://www.debian.org/doc/developers-reference/resources.html#pts-commands developers reference]] for details).||* <<Icon(star_on.png)>> Subscribe to the pkg-ruby packages (ruby1.8, ruby1.9.1, ruby-defaults) on the Packages Tracking System, and then contribute to the bug mail you get. (It is a good idea to also subscribe to bugmail from Ubuntu, see [[http://www.debian.org/doc/developers-reference/resources.html#pts-commands|developers reference]] for details).|
|Line 22:||Line 22:|
|== pkg-ruby-extras ==||== pkg-ruby-extras (libraries and applications) ==|
The Debian/Ruby Teams
The Debian/Ruby teams maintain the Ruby interpreters, libraries and applications. There are actually two different Ruby teams in Debian:
- the pkg-ruby team, which maintains the interpreter
- the pkg-ruby-extras team, which maintains libraries and applications
Both teams share some infrastructure, and have common members.
Most discussions happen on the debian-ruby mailing list. Discussions specific to pkg-ruby-extras also happen on the pkg-ruby-extras-maintainers list. You should be subscribed to both if you want to follow Ruby in Debian.
We also use IRC (#debian-ruby on irc.debian.org) quite a lot.
How you can help:
Subscribe to the pkg-ruby packages (ruby1.8, ruby1.9.1, ruby-defaults) on the Packages Tracking System, and then contribute to the bug mail you get. (It is a good idea to also subscribe to bugmail from Ubuntu, see developers reference for details).
Go through bugs, see if you can reproduce them and provide more information. Report them upstream when needed.
Checkout the Git repositories, see if you can provide a patch for some issues.
pkg-ruby-extras (libraries and applications)
Alioth Project: http://alioth.debian.org/projects/pkg-ruby-extras
Subversion repository (DEPRECATED): svn://svn.debian.org/pkg-ruby-extras/ (svn client), http://svn.debian.org/wsvn/pkg-ruby-extras/ (browser)
How you can help:
Subscribe to the lists, and start contributing to solving bugs.
Use the Packages overview to go through all existing bugs, and see if you can help with solving some of them.
Checkout the SVN repository, and see if you can improve the existing packages. There are many things that can be improved!
Mid- and Long-term tasks
Provide backports for the key Ruby packages (interpreter, rubygems) for both Debian and Ubuntu stable releases.
Revamp the libraries packaging helper
Our current approach is based on cdbs, and duplicates a lot of code between binary packages when we provide both 1.8 and 1.9.X packages. It would be much better if we only had one package when the library works with both. Also, we need somehow to work with rubygems (this is a bit too hard currently). The approach could be:
have a ?gem2tgz script that generates a clean tarball as a basis for packaging work.
have a ?dh-make-ruby script that converts the tarball into a Debian source package, using the gem metadata as a basis
- have a dh_ruby helper that would handle installing with either a modified setup.rb or a modified extconf.rb, run tests, etc.
Many things need to be well thought, like how to handle dependencies. Which makes this task quite hard to approach.
Use the alternatives system
The alternatives system would allow to easily switch between Ruby 1.8 and Ruby 1.9.X (instead of the current "/usr/bin/ruby is a symlink to ruby1.8" approach). However, this requires rethinking how we package Ruby applications and libraries, to make sure that those that only work with one particular Ruby version will be correctly treated. We cannot just break them all.