RAA Status & The Problem with Ruby

ruby-talk
21

leon breedt wrote:

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

That gives me an interesting idea. What if the unused features
for a project weren't visible?

Would that be hard to hack up? Tom C, are you reading? :wink:

I know that I for one *frequently* visit the tabs for a project
and find there is nothing there (especially the Docs).

I'd like it if the links that led to dead ends could be somehow
grayed-out or made unclickable.

Hal

22

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 disagree strongly with this "dump the RAA" verdict.

I don't understand the desire to dump something simply because it is
out of date. There is nothing wrong with its core fundamentals. Its
only problem is that it is not that up to date, but that is a solvable
problem.

If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.

The RubyForge team has always viewed RAA as THE project metadata repository
for the Ruby community. There are lots of folks (1,700+) who house over 500
ruby projects on RubyForge right now. Many don't use all the features, that
is true, but many developers don't have a place on the net to store their
code/projects...thus the reason we stood RubyForge up.

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

Worse than what? Its not worse if you have no other place to put stuff.
You don't need to use it...no one is forcing that...its just an available
service that we pay $$ for to provide something that we saw was missing.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.

It was our intent to do this, time has gotten the best of that intention,
but its 'on the list'. Our idea was to have RubyForge projects
auto-populate the RAA as those projects release files, edit their metadata,
etc. Its an integration effort that we have not had the time to do yet,
that's all. Insofar as searching for things, I agree that RAA is fast and
simple to use. It would make a nice interface plugin for RubyForge to have
the RAA search box on the main screen.

Less is more...

Leon

If less is more why use gmail :wink:

-rich

···

On 3/4/05 12:04 AM, "leon breedt" <bitserf@gmail.com> wrote:

On Fri, 4 Mar 2005 03:37:54 +0900, James Britt > <jamesUNDERBARb@neurogami.com> wrote:

23

leon breedt wrote:

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 disagree strongly with this "dump the RAA" verdict.

I don't understand the desire to dump something simply because it is
out of date. There is nothing wrong with its core fundamentals. Its
only problem is that it is not that up to date, but that is a solvable
problem.

Indeed it is; the question I'm trying to provoke is, Is that the best path?

If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.

Oh, good. *2* places to look for and download things. Which is the authorative source?

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.

Less is more...

Indeed.

How is this less? Adding another feature to RubyForge so that the RAA can duplicate, I mean mirror, an existing RubyForge feature?

The idea of mirroring select aspect of RubyForge (downloads, project/stat indices) is worth considering, but then we're no longer talking about RAA; this a new project, and simply redefining the RAA as a lightweight mirror of RubyForge is just sleight-of-hand.

James

···

On Fri, 4 Mar 2005 03:37:54 +0900, James Britt > <jamesUNDERBARb@neurogami.com> wrote:

24

+1!

(Another job for a wiki!?)

Randy Kramer

···

On Thursday 03 March 2005 08:07 am, Francis Hwang wrote:

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?"

25

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.

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?"

Those are just halvedone thoughts but I wanted to write it up. If you
look for something with a high snr don't read further.

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.

The voting website would be a possibility, or maybe just include the
possibility to browse the rpa package tree and make comments on the
packages?

The problem with this kind of things is that they are only interesting
while they sting (until you've got your needed libraries compiled and
installed) and then they are forgotten. I haven't used rpa or gems for
quite some time, because the libs I need are now installed on my
systems.

So an applause to the people doing rubforge - raa - rpa - gems etc...
you are very important, even though its only a short contact once in a
while.

sorry for the noise,

Brian

···

--
Brian Schröder
http://ruby.brian-schroeder.de/

26

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

27

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

···

On Fri, 4 Mar 2005 03:56:41 +0900, Lyle Johnson <lyle.johnson@gmail.com> wrote:

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).

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

28

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

···

On Fri, 4 Mar 2005 05:02:52 +0900, Ben Giddings <bg-rubytalk@infofiend.com> wrote:

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.

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
http://ruby.brian-schroeder.de/

29

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

···

On Fri, 2005-03-04 at 05:02 +0900, Ben Giddings wrote:

30

Lyle Johnson wrote:

On Thu, 3 Mar 2005 21:21:03 +0900, Alexander Kellett

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).

There was never any rivalry between the RPA and RubyGems teams (perhaps this
person created the appearance of one). In fact the truth was quite the
opposite -- the developers on both teams cooperated and even shared code.

Curt

31

Tom Copeland wrote:

> I pretty much agree with your assessment, but I think one more thing is
> needed. There needs to be a way 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...

How about if someone wrote a Rails app to do this? Would you be willing to
run it on the RubyForge server and modify your copy of GForge to link to it?

This would be way easier than trying to modify GForge (a PHP app) to do it
directly. I could envision a new project tab that when clicked would link to
the corresponding project review page for the same RubyForge project.

I know there are Rails developers who could create a working review and
ranking web app in less than a day. And I'm sure that we could easily find a
volunteer to do so if they knew it would be deployed and used by everyone
(everyone *does* use RubyForge, don't they? :slight_smile:

Curt

···

On Fri, 2005-03-04 at 03:54 +0900, Curt Hibbs wrote:

32

Yes, but should they have to do that to be considered alongside all the other Ruby libs? There are a number of pretty great libs that don't release to RubyForge. Personally, I use it 'cause, well, I'm lazy. But I don't think everybody should have to.

I think ideally, this would be handled generally using some basic sort of publish-update mechanism. The DOAP project is well-suited for this, and in theory could be integrated with FOAF. Then you could release your lib wherever, and ping the right servers to go slurp your updated DOAP file, then people would have a lot of personal choice as to where they host their libs.

Francis Hwang

···

On Mar 3, 2005, at 9:10 PM, Curt Hibbs wrote:

There are many projects on RubyForge that do not host their project there.
Ruby on Rails is a good example. It is hosted on its own servers, tracks
bugs and issues on its own servers, but releases RubyGems to RubyForge for
easy download and install.

33

Hal Fulton wrote:

leon breedt wrote:
>
> My major beef with the RubyForge/GForge/SourceForge is that for every
> single project you register, the assumption is made that you want the
> entire set of project lifecycle features, and clutters your project
> page with every single feature of the software. To me, thats worse.
>
> I'm not saying its not providing a valuable service. But trying to
> provide everything to everyone has never seemed to work out in the
> real world. What is RubyForge's core valuable feature? An SCM
> repository, mailing lists, and a Wiki, and stats/news on the
> registered projects, and central downloads.
>

That gives me an interesting idea. What if the unused features
for a project weren't visible?

Would that be hard to hack up? Tom C, are you reading? :wink:

I know that I for one *frequently* visit the tabs for a project
and find there is nothing there (especially the Docs).

I'd like it if the links that led to dead ends could be somehow
grayed-out or made unclickable.

You can already do that. The project admin can turn off those features and
then the tabs don't appear.

Curt

34

Each project admin can turn off tabs, but that is up to them.

···

On 3/4/05 12:20 AM, "Hal Fulton" <hal9000@hypermetrics.com> wrote:

That gives me an interesting idea. What if the unused features
for a project weren't visible?

Would that be hard to hack up? Tom C, are you reading? :wink:

I know that I for one *frequently* visit the tabs for a project
and find there is nothing there (especially the Docs).

I'd like it if the links that led to dead ends could be somehow
grayed-out or made unclickable.

35

Worse than what? Its not worse if you have no other place to put stuff.
You don't need to use it...no one is forcing that...its just an available
service that we pay $$ for to provide something that we saw was missing.

I wasn't clear: I'd rather see it opt-in than opt-out. Otherwise, it
looks like you're neglecting the project or not maintaining it (take
Rails for example), while it actually is quite active.

Perhaps the notion of being able to specify on the summary page the
primary places of activity for the project (such as the mailing lists,
wiki, bug tracker, SCM, etc) if they're non default, would help here.

It was our intent to do this, time has gotten the best of that intention,
but its 'on the list'. Our idea was to have RubyForge projects
auto-populate the RAA as those projects release files, edit their metadata,
etc. Its an integration effort that we have not had the time to do yet,
that's all. Insofar as searching for things, I agree that RAA is fast and
simple to use. It would make a nice interface plugin for RubyForge to have
the RAA search box on the main screen.

Are we really stuck with GForge in the long term? It would be great if
there were plans to switch to a Ruby framework, and a more Rubyist
approach was taken to the design of the site. Especially if the design
folks behind the ruby-lang.org redesign had a hand in the appearance
and UI. I understand it would be a massive migration effort though.

Apologies if my tone was a little harsh...I am a happy RubyForge
resident, just calling things as I thought I saw them.

Leon

···

On Fri, 4 Mar 2005 14:29:39 +0900, Richard Kilmer <rich@infoether.com> wrote:

36

Oh, good. *2* places to look for and download things. Which is the
authorative source?
How is this less? Adding another feature to RubyForge so that the RAA
can duplicate, I mean mirror, an existing RubyForge feature?

UI matters, and, I'd want the directory/search interface of the One
True Source to be as close to RAA/search.cpan.org as possible in terms
of UI.

search.cpan.org is the single biggest thing Perl has going for it.
That doesn't mean people don't use things like SourceForge. But
SourceForge isn't exactly where people go to find Perl modules, maybe
50 versions back, or browse through available modules. There's too
much ancillary information hitting you in the face at SF, when all you
want to do is find a project. I would argue a directory to be a better
starting point, with the directory pointing at more details about the
project.

The idea of mirroring select aspect of RubyForge (downloads,
project/stat indices) is worth considering, but then we're no longer
talking about RAA; this a new project, and simply redefining the RAA as
a lightweight mirror of RubyForge is just sleight-of-hand.

I have no idea where the best place for these mirrors would be, I
chose RAA arbitrarily. RAA could point at the RubyForge mirror
location, for all I care :slight_smile:

Leon

···

On Fri, 4 Mar 2005 15:04:45 +0900, James Britt <jamesUNDERBARb@neurogami.com> wrote:

37

leon breedt wrote:
> I'm not saying its not providing a valuable service. But trying to
> provide everything to everyone has never seemed to work out in the
> real world. What is RubyForge's core valuable feature? An SCM
> repository, mailing lists, and a Wiki, and stats/news on the
> registered projects, and central downloads.
>

That gives me an interesting idea. What if the unused features
for a project weren't visible?

Would that be hard to hack up? Tom C, are you reading? :wink:

Always :slight_smile:

I'd like it if the links that led to dead ends could be somehow
grayed-out or made unclickable.

Yup, a project admin can go into the "admin" and then "edit public info"
page and deselect whatever he's not using.

Yours,

Tom

···

On Fri, 2005-03-04 at 14:20 +0900, Hal Fulton wrote:

38

Francis Hwang(sera@fhwang.net)@2005-03-03 22:07:

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

Maybe some tool should be created that can be voluntarily installed on
any computer. Based on the debian "popularity contest" the tool would
track library usage and report statistics via email for tally at a
central site.

That would give a pretty good idea about which libraries are really
being used and which are dead.

Steve

39

Randy Kramer wrote:

> 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?"

+1!

(Another job for a wiki!?)

A wiki would not be the best choice for this. Anyway, this is what should be
built in to RAA.

Curt

···

On Thursday 03 March 2005 08:07 am, Francis Hwang wrote:

40

Very true! I remember converting my Outlook data to Evolution; there
were some bugs with the import/export routines. But once I had my data
moved over, my motivation to go back and hack on that code was nil.

So I +1 your props to the Gems guys. :slight_smile:

Yours,

Tom

···

On Thu, 2005-03-03 at 23:12 +0900, Brian Schröder wrote:

The problem with this kind of things is that they are only interesting
while they sting (until you've got your needed libraries compiled and
installed) and then they are forgotten. I haven't used rpa or gems for
quite some time, because the libs I need are now installed on my
systems.