RAA Status & The Problem with Ruby

[Mark Probert]

Hi ..

I don't think it's a given that just because a certain library gets
knighted as part of an "extended stdlib" that it will automatically be
well-maintained and well-documented. In fact, there are more than a few
libs in the _actual_ stdlib that have fairly crummy documentation even
today.

The "usual" way around this are standards and review. If a library fails to
meets its obligations, poor documentation or whatever, then perhaps it
shouldn't make it into the general release. I am not sure how this would
work for Ruby though. Certainly, the place to start is the current library.

The second part about the libraries is one of use. There are certain
libraries that I use all the time and couldn't live without. There are
others that are essential to me every now and then (including my own ones).
And there are others that are just cool to look at and get ideas from.

It is the now-and-then libraries that would seem to be the biggest issue. For
example, if I need an database wrapper class, what am I going to use? How do
I find out which one suits my needs? Documentation is a big part, the honest
comments from users to whom these libraries are essential is another.

So, perhaps the best initial first step is to provide a user-feedback option
to RAA and rate the programs a la Tucows or similar.

Sorry for the ramble ..

 

[vruz]

I was never quite clear on how RPA was supposed to do this. Not to

criticize the work of Mauricio and others, but it seemed to me to have
a scaling problem: If you have a few volunteers trying to evaluate
hundreds of Ruby libs, they're not going to have time to really
evaluate them.

First of all, RPA was never intended to replace RAA.

RAA has been used as an important source of original, pristine
packages provided by developers.
As RPA encourages a number of 'Good Practices' , it is the aim that
developers have these general guidelines into account to make their
works more easily packageable for production use.

Ultimately, if every developer out there loosely followed these
recommendations, (which we believe are a good balance between
simplicity, portability and scalability ie: 'packageability') in the
future, RPA would be becoming more like RAA, and RAA more like RPA.
(but that doesn't mean RAA will cease to co-exist and evolve, RPA is
not trying to be THE standard)

What RPA is supposed to do can be read here:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto

The recommended Good Practices:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices

Good API Design:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign

Packaging Nitpick Checklist:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?PackagingNitpickChecklist

About the scaling problem, with respect to its developer base, it has
the potential of being as scalable as any other open source project.

If you're talking about volunteers' turnaround efficiency, I
personally remember I found an undeclared dependency in Lafcadio,
understood the problem, reported it and it was fixed in the
corresponding RPA package within 24 hs. just to give an example.
I personally tested dozens of packages in at least 3 platforms.

If the scalability problem you see is in the number of volunteers or
the culture they're trying to foster, I'm sorry but I can't answer
that.

Do you know how volunteers have been consistently and actively
discouraged from joining the project ?
How do you think that could be fixed ?

Positive input is welcome.

I'd like to see some sort of a website where Rubyists can sign on and
then vouch for given libraries that they use from day to day. You'd be
able to search for libs based on who else is using them--it'd be, at
the least, a more automated way to find community opinion than emailing
ruby-talk and asking "What do people use when they're trying to use
Ruby with XYZ problem?"

Finally, in your last statement, I absolutely agree with you.

I'd greatly appreciate a more automated (politically unaware,
meritocratic) way to find unbiased information to learn about real
working and useful technology.

cheers,
vruz

 

[vruz]

I really like a package system like rpa, and its great that there are

people actually doing the work of packaging libraries. If one looks at
the debian project, it is obviously quite scalable to seperate
upstream developers from packagers.

So I +1 your props to the RPA guys.

cheers,
vruz

 

[Bill Guindon]

So I +1 your props to the RPA guys.

I'll jump on that bandwagon too, and I'll add a +1 for the folks at
RubyForge. I look there first, and use RAA as a backup plan.
RubyForge seems to be much more active, and far more up to date than
RAA, but that's just my take on it.

 

[James Britt]

Below, I posting the entire text of this blog entry:

http://sean.typepad.com/ditto/2005/03/the_problem_wit.html

I think that this guy has really called it right. There have been a few
postings about a reworking of RAA... does anyone know the current status of
this effort?

Curt

==========================
http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
The Problem with Ruby

<snip/>

Some possible solutions:

1. Dump the RAA.
Don't bother fixing it.
Tell people to move their code to RubyForge.

2. Dump the RAA
Tell people to find a home page for their
project and include "RAA" and "Ruby" in the keyword meta tag,
and let Google do the rest.

2. Dump the RAA
Tell people to find a home page for their
project and tag it on del.icio.us with the tags 'Ruby'
and 'RAA', plus a brief description.

I get the sense that this blogger's opinion was based entirely on what
he saw at the RAA. RAA has pretty much fallen off my radar; If I'm
looking for a Ruby app or lib I turn to RubyForge or Google. The RAA
has tended to be too incomplete or out-of-date. I've listed things
there but have more or less forgotten about their respective pages; it
is just too much extra work to have a project, maintain the README and
home page for that project; AND have to duplicate much of that
information someplace else.

RubyForge was a godsend (thanks, InfoEtherites!) if for no other reason
that it facilitates one-stop shopping for both developer and end-user.

The RAA may be like a few other things in Rubyland: a good and
appropriate idea at the time of conception, but possibly past its prime
or superseded by more effective tools and infrastructure.



James

 

[Curt Hibbs]

<snip/>

Some possible solutions:

1. Dump the RAA.
Don't bother fixing it.
Tell people to move their code to RubyForge.

2. Dump the RAA
Tell people to find a home page for their
project and include "RAA" and "Ruby" in the keyword meta tag,
and let Google do the rest.

2. Dump the RAA
Tell people to find a home page for their
project and tag it on del.icio.us with the tags 'Ruby'
and 'RAA', plus a brief description.

I get the sense that this blogger's opinion was based entirely on what
he saw at the RAA. RAA has pretty much fallen off my radar; If I'm
looking for a Ruby app or lib I turn to RubyForge or Google. The RAA
has tended to be too incomplete or out-of-date. I've listed things
there but have more or less forgotten about their respective pages; it
is just too much extra work to have a project, maintain the README and
home page for that project; AND have to duplicate much of that
information someplace else.

RubyForge was a godsend (thanks, InfoEtherites!) if for no other reason
that it facilitates one-stop shopping for both developer and end-user.

The RAA may be like a few other things in Rubyland: a good and
appropriate idea at the time of conception, but possibly past its prime
or superseded by more effective tools and infrastructure.

I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.

Curt

 

[Lyle Johnson]

this issue comes up every few months.
yet the last real answer (rpa) basically
disappeared into the mist because people
are far more interested in talking about
the problems than actually taking some
action.

In my opinion, the lack of support for the RPA had a lot to do with,
for lack of a better phrase, poor public relations.

A certain person attached himself to the RPA project and proceeded to
make enemies of pretty much everyone in the Ruby community. If you
were hanging out on ruby-talk and/or the #ruby-lang IRC channel during
that unfortunate period, you know who I'm talking about. He seems to
have moved on, to troll in browner pastures, and for that reason it
might be a good idea for us as a community to reconsider the merits of
RPA.

A related problem, which I think had a lot to do with that person, was
that there was this "rivalry" of sorts set up between the RubyGems
packaging system and RPA, and although I never saw them as competing
efforts, it seemed to be the case that one of them had to "win". My
understanding of the RPA effort was that it had a lot to do with
quality control issues and was not quite so hung up on the packaging
approach (as long as the packaging approach was consistent).

 

[Tom Copeland]

I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.

Simon Strandgaard suggested something like this a while back:

http://tinyurl.com/6s8ds

It could be cool...

Yours,

Tom

 

[Daniel Berger]

Curt Hibbs wrote:

I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.

Curt

What we need to keep from the RAA:

* The recent/new uploads page
* The ability to list dependencies
* The categorization (per package, not per project)

I still like the front end stuff (name, date released, date updated,
description, etc) that you can do per package. And, since there's a
database backend on all of this, I'm not sure how you tie it into
RubyForge.

But, if someone can merge the RAA and RubyForge into one big happy
entity, I'm all for it.

Regards,

Dan

 

[Austin Ziegler]

A related problem, which I think had a lot to do with that person, was
that there was this "rivalry" of sorts set up between the RubyGems
packaging system and RPA, and although I never saw them as competing
efforts, it seemed to be the case that one of them had to "win". My
understanding of the RPA effort was that it had a lot to do with
quality control issues and was not quite so hung up on the packaging
approach (as long as the packaging approach was consistent).

While it is certainly true that the RPA team never saw this as a case
of "one has to win," the RubyGems team has moved on the assumption
that eventually the packaging format will be integrated with Ruby at
the core. The RPA team built its own packaging format because of
perceived or actual deficiencies in the model used by RubyGems, and in
some cases, at least, they were correct -- and RubyGems has since
improved.

I personally don't know enough about packaging formats to say for
sure. I do think that it would be beneficial if the RPA packaging team
worked with the RubyGems team to provide a *single* standard packaging
system that could be integrated into Ruby and accepted by Matz. This
would make distribution and deployment much easier in so many ways for
both developers and repackagers that it wouldn't be funny.

I don't think that the two goals are incompatible. I think that how
RubyGems does things could be integrated into how the RPA team has
said it wants to do things (e.g., the RPA team is more focussed on
stable releases of groups of packages than on multiple package
versions being available and independently selectable, but with what
seems to be only a few changes in metadata, this could be made part of
RubyGems).

-austin

 

[Ben Giddings]

I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.

When I saw the description of the problem, I immediately thought of how
the same is true of Sourceforge, but how one of the first things I look
for on a new Sourceforge project page is the "activity percentile" and
the last update.

Does RubyForge have similar features? If not, how hard would it be to
add to RubyForge some automated way of deciding how reliable a library
is likely to be based on a combination of:
* when it was last updated
* when it was first created
* how many people use (download) it

IMHO, as a relatively new, English-speaking Ruby programmer, I'd say
"dump RAA, use RubyForge, dump RPA, use RubyGems". Any features that
are not in RubyGems that are in RPA could probably be put in there...
though they are different goals. I think growing the already-successful
RubyGems is the easier, and more natural solution.

As for RAA vs RubyForge, RAA may be actively used by our Japanese
friends, but unless they need it, it seems like it's really broken and
maybe shouldn't be fixed.

Ben

 

[Brian Schröder]

When I saw the description of the problem, I immediately thought of how
the same is true of Sourceforge, but how one of the first things I look
for on a new Sourceforge project page is the "activity percentile" and
the last update.

Does RubyForge have similar features? If not, how hard would it be to
add to RubyForge some automated way of deciding how reliable a library
is likely to be based on a combination of:
* when it was last updated
* when it was first created
* how many people use (download) it

IMHO, as a relatively new, English-speaking Ruby programmer, I'd say
"dump RAA, use RubyForge, dump RPA, use RubyGems". Any features that
are not in RubyGems that are in RPA could probably be put in there...
though they are different goals. I think growing the already-successful
RubyGems is the easier, and more natural solution.

As for RAA vs RubyForge, RAA may be actively used by our Japanese
friends, but unless they need it, it seems like it's really broken and
maybe shouldn't be fixed.

Ben

I'm not really good informed, but as far as I know to use ruby gems
you need to change the sourcecode of your program, while rpa is a real
package installer that installs libraries into the search path. If
this is wrong, please correct me. Because somehow this information
came into my head, I decided to use rpa over rubygems.

That gems is older than rpa is not neccisarily a good sign - maybe
experience has brought better ideas into rpa. But I'm no expert and
don't want to start another rpa vs. gems war.

best regards,

Brian

 

[Guillaume Marcais]

I'm not really good informed, but as far as I know to use ruby gems
you need to change the sourcecode of your program, while rpa is a real
package installer that installs libraries into the search path. If
this is wrong, please correct me. Because somehow this information
came into my head, I decided to use rpa over rubygems.

You don't really need to change your code. I have RUBYOPT=-rrubygems set
in my environment and I can use gem libraries completely seamlessly.

Guillaume.

 

[Jim Weirich]

Brian Schröder said:

I'm not really good informed, but as far as I know to use ruby gems
you need to change the sourcecode of your program, while rpa is a real
package installer that installs libraries into the search path. If
this is wrong, please correct me.

This is incorrect.

You do need to assure that the rubygems package manager is loaded in order
to take advantage of any gems on your system. There are basically three
options:

(1) Do a "require 'rubygems'" in your code.
(2) Launch the script with an explicit -rubygems on the command line
(e.g. ruby -rubygems your_script_name.rb)
(3) Set the RUBYOPT environment variable to be "rubygems".

(2) and (3) require no changes to a code base in order to work with gem
libraries. I tend to use (3).

If you wish to lock down particular version of a library, then you are
free to use the require_gem command and supply an explicit version
constraint. I know that some folks using rails have done this to support
multiple versions of rails on a single server. This is handy because
different web apps were written against different versions of rails over
time.

But if you don't need the explicit versioning, just a regular require
works just fine.

 

[Tom Copeland]

When I saw the description of the problem, I immediately thought of how
the same is true of Sourceforge, but how one of the first things I look
for on a new Sourceforge project page is the "activity percentile" and
the last update.

Does RubyForge have similar features?

Yup, there's an activity percentile thingy:

http://rubyforge.org/top/

If not, how hard would it be to
add to RubyForge some automated way of deciding how reliable a library
is likely to be based on a combination of:
* when it was last updated
* when it was first created
* how many people use (download) it

The above pages should do that. I don't really grok the code that
generates those percentages, though, as noted in this bug posted by Ryan
Davis:

http://tinyurl.com/66f2m

Yours,

Tom

 

[Ben Giddings]

If you wish to lock down particular version of a library, then you are
free to use the require_gem command and supply an explicit version
constraint. I know that some folks using rails have done this to support
multiple versions of rails on a single server. This is handy because
different web apps were written against different versions of rails over
time.

IMHO that's a shortcoming of Ruby's "require" statement to begin with.
It would be handy to be able to "require" a particular version of a
library, if you know that more recent ones don't work for you. Maybe in
Ruby 2.0 Matz can spruce up "require" a bit.

Anyhow, I never fully understood what RPA was all about, and how it was
suppose to interact with my system's package manager. It seems like RPA
was partially about solving the fundamental problem of scattered
libraries with differing install methods, bad docs, etc. But it was
also about trying to provide a package management/installation system.
I didn't really understand how it was supposed to work together with my
system's package manager.

RubyGems was about distributing and updating libraries and apps, but
seemed more orthogonal to the system package manager because it
installed things in a special 'gems' area. Maybe the two can be
combined, so that RubyGems adopts the quality assurance aspect of RPA
while keeping it's package management abilities. Maybe it would be
possible to sort RubyGems into 'stable' and 'unstable'. A requirement
to get to stable would not just be a lack of crashing, but to have good
docs, a stable API, and be generally well-behaved.

To be effective though, someone would have to judge what qualifies as
'stable'. There would also need to be a way to demote packages from
'stable' to 'unstable' if serious bugs come up, or the packages become
unmaintained, etc.

This sounds like it would do what the RPA project was trying to do. I
*really* appreciate the effort that went into RPA, but it really seems
like there's a needless duplication of effort going on.

I love open source software, and I love the choice it offers me. On the
other hand, sometimes it's annoying that there's BSD and Linux, Emacs
and XEmacs, KDE and Gnome, RAA and rubyforge, RubyGems and RPA. If the
RPA and RubyGems folks could get together and come up with the One True
Ruby Package Management System... that would be a momentous day. I'm
sure the streets would be filled with cheering people, the skies would
open and rainbows would fill the sky, and Ruby would be that much closer
to taking over the world (benevolently of course).

On the other hand, maybe I'm wrong and RPA and RubyGems should stay
separate projects. *shrug* (I do like rainbows though)

Ben

 

[Ben Giddings]

The above pages should do that. I don't really grok the code that
generates those percentages, though, as noted in this bug posted by Ryan
Davis:

If nobody understands what the stats mean, or where they come from, are
they all that useful? Maybe we should suggest a replacement as a Quiz
topic, or something similar. Given:
* The date a project was registered
* The number of times the web page was accessed
* The number of times the binary was downloaded
* The frequency of CVS commits
* The date of the last binary release
* The version number of the project

Find a way to turn that into a human-understandable idea of how risky it
would be to use this library in a project.

Ben

 

[Eric Hodel]

--Apple-Mail-60-584847773
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

If nobody understands what the stats mean, or where they come from,
are they all that useful? Maybe we should suggest a replacement as a
Quiz topic, or something similar. Given:
* The frequency of CVS commits

How would you handle projects that don't use RubyForge CVS? That don't
use CVS?

* The version number of the project

MyNewProject v2000.0.0

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-60-584847773
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCJ44mMypVHHlsnwQRArwgAJwM9r4jggIaaACtsH98zvcKlbAk5wCdGkee
ZxCrePZFHjZOOrV+tZaN8zg=
=rm6I
-----END PGP SIGNATURE-----

--Apple-Mail-60-584847773--

 

[Marcelo Paniagua]

Has anyone checked RDE (Ruby Development Enviroment)? in SourceForge?

I just downloaded and I will try it.

http://sourceforge.net/projects/rubyde/

 

[Tom Copeland]

If nobody understands what the stats mean, or where they come from, are
they all that useful?

Well, the stats are somewhat understood - they're based on totting up
all the bugs/downloads/pageviews/CVS checkins/forum posts for a project
and then munging them. But if I was pressed to explain exactly why a
project had a 0% activity percentile on a particular day, I would wander
off for a cup of coffee.

Yours,

Tom