[DRE-maint] Team goals

Wed Mar 19 03:41:07 UTC 2008

Paul van Tilburg dijo [Wed, Mar 12, 2008 at 10:22:34PM +0100]:
> Hello everyone, 
> 
> With 77 packages now maintained by the team[1], I can say that we have
> succeeded in packaging a lot of libraries and applications.  I also
> think that the quality is quite high and I hope you think so too.  :)
> We also have created the libruby-extras packages, another goal that we
> have met in the latest stable release.  Discussing with Lucas and Duck
> on FOSDEM 2008 have made me realise that we need new goals.  Most of
> them are known to most of us, but it might be good to formulate them
> anyway.

I have not been as involved as I'd like, by far. I'm into some sort of
personal mess lately, but I do hope to be able to claim again some of
the time I used (and plan!) to devote to Debian.

> I propose the following team goals (in no particular order)
> 
> 1) Full documentation support.
> 
>  For me, the usefulness of a library stands or falls with the
>  availability of good documentation.  While the documentation may be
>  present in the source, we need to export this and put it in standard
>  places.  This means:
>   - Install upstream or generated RDoc HTML documentation in
>     /usr/share/doc/lib<foo>-ruby/rdoc/.
>   - Install upstream or generated RDoc RI documentation.  This might
>     involve patching ri and devising a good system to do this.
>   - Registering all documentation with doc-base!

BTW... I am not really for splitting our packages into
libfoo-ruby{,version} and libfoo-ruby-doc - Yes, it is a considerable
size difference against a single package. But then again, our packages
are seldom very large!

> 2) RubyGems support.
>  
>  RubyGems exists, there is no way we can keep ignoring it.  Any lanuage
>  is prone to develope something CPAN/CTAN/...-like at some point anyway.
>  IMO we need to adapt our position statement and approach the issue from
>  the following three aspects:
>
>  (...packagers, developers, users...)

Sadly, the way Gems are implemented is as nonsensical as it gets!
Anyway - your characterization of the three groups is right. 'gem'
should work in Debian as it does elsewhere. But Debian-packaged
software should not require anything not in Debian. No news here,
right? :)

> 3) Multiple interpreter support.
>   
>  Although we seem to be able to support multiple Ruby interpreter, this
>  does not really work that well.  Take for example JRuby or Ruby 1.9. 
>  At the moment, we ignore jruby alltogether and there are only a few
>  -ruby1.9 lib packages.  Besides that, we keep having the problem of
>  this whole -rubyX.Y package clutter.  It has been suggested to follow
>  the Python and or Perl way or a combination.
>  I know we have to do this with all Debian/Ruby devs, but as a team we
>  can push for changes.
> 
> I don't know which of these goals should be our Lenny release goals or
> something, but... we should try to work towards the three goals as hard
> as we can and we'll see where we end up.
> 
> I would very much welcome your thoughts, comments or ideas!

Yes, this is a tough spot, and it is inherent to the constant state of
flux in the Ruby community. Rubyists are simply not very compatible
with Debian. 

I think we _do_ have to solve the multiple interpreter problem. I am,
however, unable to aid here - I'm still a newbie in working with Ruby
as a packager, and don't really know the Ruby versioning details. But
I do know the Perl 5.6->5.8->5.10 transitions have been relatively
easy and smooth (of course, call smooth a mass-RC-bug-filing because
most packages FTBFS - but they are easily fixable and most are closed
already). But Ruby's changes, AIUI, are far more invasive. And as we
are now, I don't think this is realistic as a release goal for Lenny -
But we shold still keep it as work to do.

I'd like to add a point to yours: Although by far it's not the only
use, a very important attractor to this language has been Rails. Now,
besides gems, Rails developers are quite fond of plugins. They are
installed inside the application tree itself (in
vendor/plugins). Maybe we could somehow work it out the same way Rails
itself is managed (vendor/rails, vendor/active*, etc.), via symlinks
to installed packages and such. 

I have exchanged a couple of mails with Adam Majer, the Rails
maintainer. He is a very good maintainer, but is the sole maintainer
of Rails. I think we should also get him to sinergyze with us. 

Anyway - I'd also like to put some time into integrating our workflow
towards the QA report [1] that mainly Gregor, Tincho and Damyan have
put for the Perl group. I understand several other Debian groups are
using this work, and our repositories' structure is quite similar
(except that the Perl group has the full upstream sources in the
repository, not just the diffs).

[1] http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi

-- 
Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF