Differences between revisions 3 and 16 (spanning 13 versions)
Revision 3 as of 2007-05-26 21:36:03
Size: 1514
Editor: ?VincentFourmond
Comment:
Revision 16 as of 2010-10-18 14:14:34
Size: 4154
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= The Debian/Ruby Extras Team = = The Debian/Ruby Teams =
Line 3: Line 3:
== Task description == The Debian/Ruby teams maintain the Ruby interpreters, libraries and applications. There are actually two different Ruby teams in Debian:
 * the pkg-ruby team maintains the interpreter
 * the pkg-ruby-extras team maintains libraries and applications
Line 5: Line 7:
The Debian/Ruby Extras team maintains libraries and applications written in and for the Ruby language. The Ruby interpreter itself is not a responsibility of the team, though we strive to maximize our cooperation with the Ruby maintainers. Most discussions happen on the [[http://lists.debian.org/debian-ruby/| debian-ruby mailing list]]. Discussions specific to pkg-ruby-extras also happen on the [[http://lists.alioth.debian.org/mailman/listinfo/pkg-ruby-extras-maintainers | pkg-ruby-extras-maintainers list]]. You should be subscribed to both if you want to follow Ruby in Debian.
Line 7: Line 9:
The teams also maintains the ''ruby-pkg-tools'' package, a set of useful tools for anyone who wishes to make debian packages from Ruby libraries of programs. We also use IRC (#debian-ruby on irc.debian.org) quite a lot.
Line 9: Line 11:
== Infrastructure == == pkg-ruby ==
Line 11: Line 13:
 * '''Website''': http://pkg-ruby-extras.alioth.debian.org/  * '''Alioth Project''': http://alioth.debian.org/projects/pkg-ruby
 * '''Subversion repository''': svn://svn.debian.org/pkg-ruby/ (svn client), http://svn.debian.org/wsvn/pkg-ruby/ (browser)

How you can help:
 * <<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)>> Go through bugs, see if you can reproduce them and provide more information. Report them upstream when needed.
 * <<Icon(star_on.png)>><<Icon(star_on.png)>> Checkout the SVN repository, see if you can provide a patch for some issues.

== pkg-ruby-extras ==

 * '''Team Documentation''': [[/RubyExtras]]. In particular, see the [[/RubyExtras/JoiningTheTeam|Joining the Team]] page.
Line 14: Line 26:
 * [[http://qa.debian.org/developer.php?login=pkg-ruby-extras-maintainers%40lists.alioth.debian.org&comaint=yes|Packages overview]]
 * [[http://pkg-ruby-extras.alioth.debian.org/cgi-bin/pet.cgi|PET overview]]
How you can help:
 * <<Icon(star_on.png)>> Subscribe to the lists, and start contributing to solving bugs.
 * <<Icon(star_on.png)>> Use the Packages overview to go through all existing bugs, and see if you can help with solving some of them.
 * <<Icon(star_on.png)>><<Icon(star_on.png)>> Checkout the SVN repository, and see if you can improve the existing packages. There are many things that can be improved!
Line 15: Line 33:
== Interacting with the team == == Mid- and Long-term tasks ==
Line 17: Line 35:
 * '''Email''': [[MailTo(pkg-ruby-extras-maintainers AT lists DOT alioth DOT debian DOT org)]]
 * '''IRC''': most of the members of the time reside on #debian-ruby on irc.debian.org (OFTC)
=== Backports ===
<<Icon(star_on.png)>>
Provide backports for the key Ruby packages (interpreter, rubygems) for both Debian and Ubuntu stable releases.
Line 20: Line 39:
== Useful links == === Revamp the libraries packaging helper ===
<<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>>
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|gem2tgz]] script that generates a clean tarball as a basis for packaging work.
 * have a [[/dh-make-ruby|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.
Line 22: Line 48:
 * [http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=pkg-ruby-extras-maintainers%40lists.alioth.debian.org BTS page]
 * [http://qa.debian.org/developer.php?login=pkg-ruby-extras-maintainers%40lists.alioth.debian.org&comaint=yes Packages overview]
 * [http://pkg-ruby-extras.alioth.debian.org/subversion.html Team's Subversion Guide]

== Get involved ==

Just contact us via email or on IRC, or have a look at the [http://pkg-ruby-extras.alioth.debian.org/join.html Joining the Team] page
=== Use the alternatives system ===
<<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>>
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.

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 maintains the interpreter
  • the pkg-ruby-extras team maintains libraries and applications

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.

pkg-ruby

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 http://www.debian.org/doc/developers-reference/resources.html#pts-commands developers reference for details).

  • {*} Go through bugs, see if you can reproduce them and provide more information. Report them upstream when needed.

  • {*}{*} Checkout the SVN repository, see if you can provide a patch for some issues.

pkg-ruby-extras

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

Backports

{*} 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.