RAA Status & The Problem with Ruby

[leon breedt]

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

Leon

 

[gabriele renzi]

James Edward Gray II ha scritto:

This is a silly simple idea that could do a lot. Test listings once a
day and if there are broken links in your listing it gets pulled from
public display until you fix it. I like that idea.

maybe no need to check every day. A full link-check cycle every week or
two week would be good anyway, if the information "this peoject was
checked x days ago" was made available

 

[gabriele renzi]

Sam Roberts ha scritto:

If it was a way of distributing and downloading packages, I would be a
huge fan. For some reason, they added this "feature" that forces changes
in the language, a feature that python, perl, tcl all do without in
their package management, as far as I know.

IIRC Tcl has something like
package require version > x.y.z

I think you have to consider that rubygems does what he do since it
means to be integrated into core ruby. Once this happens you won't need
more hacks. This does not relieve of the needs for QA, anyway.

 

[NAKAMURA, Hiroshi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Yukihiro Matsumoto wrote:
| Improving RAA is another story. Maybe we should add it a few more
| features, such as
|
| * rating system
| * dead link check
| * accepting update information from anyone (pages will be updated
| after the moderator check)

Here's a result of a dead link check I did today.
http://raa.ruby-lang.org/announce20050304.html

As a side effect of the check, here are caches of homepage/downloadable
item.
http://raa.ruby-lang.org/cache/

Regards,
// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCKFY6f6b33ts2dPkRAvxzAJ4hoSC10AcFNK36S+X37tCuj3lgmgCdGPts
ZxLw0jk4m6sp/HHm6qCDLC0=
=fpal
-----END PGP SIGNATURE-----

 

[vruz]

As a side effect of the check, here are caches of homepage/downloadable

item.
http://raa.ruby-lang.org/cache/
Regards,
// NaHi

that's great, what's the current policy ?
for how long do things remain in the cache ?

are there any other 'undocumented' RAA features available ?

cheers,
vruz

 

[James Britt]

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.

This is an appealing idea. The fewer places a developer needs to go to
update information, the more reliable that information will be.

I would be nice to have a Rake task that pulls together various bits of
information, assembles descriptor file, and pings some server to
indicate New Stuff. (Though I believe that RAA has or had a SOAP
interface, so something like this may be doable now.)


James

 

[Chad Fowler]

1. Make RubyGems transactional. This is one of the things that I
think that Mauricio got absolutely right. As it stands now, I
think that it is possible for a RubyGem install to fail in the
middle and leave me in a state where I can partially include
something.

2. Make RubyGems aware of the package files that it owns. This is
what RPA did to ensure that it could install the library into
the core library area without breaking anything else.

3. Provide patches to 1.8.x and probably 1.9 that would replace
the require functionality with the RubyGems require, but
faster. See the RubyGems/rails performance boost tip someone
(Jamis?) found some time back. That startup performance hit is
a strong negative against RubyGems. RPA didn't face this
because it *did* put the package files in the core.

If you go back and look at Jamis's post, you'll see that he was
running an older version of RubyGems at the time and the performance
issues had already been fixed.


--

Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)

 

[Tom Copeland]

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?

Always

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

 

[Tom Copeland]

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.

Yup, that's the rub - there's a lot of data in the 50+ table GForge DB
schema, and moving that data elsewhere would be tricky.

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

No offense taken! It's good to discuss these things...

Yours,

Tom

 

[Chad Fowler]

Hi,

In message "Re: RAA Status & The Problem with Ruby"

|* Central repository (RAA?), mirrored, containing the (1) and (2)
|artifacts, and only serving downloads for the "installer" below.

RAA would refuse to be a central repository. Despite the name, it is
(and will be) the central _index_ of the various Ruby projects. RPA
might be a candidate for the central.

Matz, I don't think RPA's goal was so much to be the _physical
repository_ of its packages (though that is a necessary side effect)
as it was to be a QA'd group of packages.

RubyGems also has the concept of a repository, which is where
libraries come from when you do: gem install libraryname.

I see RubyGems as being the packaging extension of the RAA. RAA (and
RubyForge) support traditional open source bazaar-mode development.
The same is true of RubyGems. Some libraries might not work. Some
may be of alpha quality. Some may rm -rf your system if you're not
careful. RPA's goal was to QA and validate libraries so that only
ones that the RPA team deemed of being high quality were included in
the RPA release.

The packaging system and repository were requirements that the RPA
team felt were necessary for their _actual_ vision to be realized.

So, to expand on your original statement, we actually have three
things (or four):

1. Package format
2. Package repository
3. QA / Validation process (RPA)
4. Package index (RAA)

I see RubyGems filling the needs of #1 and #2. In fact, I see it
actually filling those needs for > 200 packages and literally
thousands of users today.

As with any library or application, there are bound to be rough edges
in RubyGems. But, it keeps improving, and it will keep improving
through the efforts of the volunteers that maintain it and the
cooperation of the hundreds or thousands of users who are using it
daily and submitting bug reports and feature requests.

Someone made the point that Python, TCL, Perl, etc. don't have the
versioning concept that RubyGems has. My point exactly.

--
Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)

 

[Ben Giddings]

So, to expand on your original statement, we actually have three
things (or four):

1. Package format
2. Package repository
3. QA / Validation process (RPA)
4. Package index (RAA)

I see RubyGems filling the needs of #1 and #2. In fact, I see it
actually filling those needs for > 200 packages and literally
thousands of users today.

Chad, do you think it's possible to combine what RPA wanted to offer,
and what RubyGems wanted to offer? For instance, to maybe be able to
tag RubyGems packages as being "stable" and "unstable". Packages tagged
as "stable" would have passed the RPA QA process, by default everything
else would go in "unstable"?

Do you think the different approach to packaging / format of the
packages is a matter of concern? Maybe the standard "Gem" format could
be one of a few different "renderings" of the package. That way, you
could also "render" as a .rpm or as a .deb or an RPA package.

I'd love to see the QA aspect of RPA combined with the repository /
format aspect of RubyGems. I also think that if there were "one true
approach" to packaging Ruby libs and apps, it would bring people (like
me) in from the sidelines to start actively using one or the other.

Ben

 

[NAKAMURA, Hiroshi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

vruz wrote:
|>As a side effect of the check, here are caches of homepage/downloadable
|>item.
|>http://raa.ruby-lang.org/cache/
|
| that's great, what's the current policy ?
| for how long do things remain in the cache ?

There's no policy defined yet. I just open-uri-ed URLs and just saved
there... I can be able to keep the caches there but it will be dud soon
because it won't be updated on a routine basis. The script I wrote just
open-uri-ed URLs, without checking/comparing local cache viridity (by
If-Modified-Since, HTTP HEAD or etc.) It's a side effect of link check
at this time.

| are there any other 'undocumented' RAA features available ?

She knows herself: http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/app/raa/
~ Joking aside, feel free to ask me about it though there's no
unpublished feature I think.

Regards,
// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCKIimf6b33ts2dPkRAmsiAJ4vDZBq3VsiY6PxPG2GbsbA4+4IFwCgvssB
8feGKLIlzqAAWK2dTRHX4dU=
=/d4x
-----END PGP SIGNATURE-----

 

[Chad Fowler]

Chad, do you think it's possible to combine what RPA wanted to offer,
and what RubyGems wanted to offer? For instance, to maybe be able to
tag RubyGems packages as being "stable" and "unstable". Packages tagged
as "stable" would have passed the RPA QA process, by default everything
else would go in "unstable"?

Definitely. There has been much discussion about this. Search
ruby-talk for an exhausting several hours of reading You wouldn't
really need to even do the stable/unstable thing. It would be
possible to create a super-gem ("gems-quality-assured" or something)
that has all of the known good versions as dependencies. That would
at least get the good ones on your system. If you _only_ installed
the super-gem, you would in effect have a full local installation of
someone's known-good list. This could be done without any changes to
RubyGems at all. What it _wouldn't_ give you is the ability to patch
the libraries, which the RPA people were doing with some of the libs
they were touching. You'd have to depend on the traditional
send-patch-and-wait method of getting patches into a library.

Do you think the different approach to packaging / format of the
packages is a matter of concern? Maybe the standard "Gem" format could
be one of a few different "renderings" of the package. That way, you
could also "render" as a .rpm or as a .deb or an RPA package.

Doing this with Rake would be ideal. Personally, as long as there is
a universally available format with a _lot_ of libraries to be had,
I'd be happy. As of now, RubyGems is filling that role to a great
extent. If people want to create .rpm, .deb, and .rpa packages,
that's also great. I just want it to be easy to find and install Ruby
stuff. These days, it's much much easier than it was two years ago.
And it keeps getting better and better.

I'd love to see the QA aspect of RPA combined with the repository /
format aspect of RubyGems. I also think that if there were "one true
approach" to packaging Ruby libs and apps, it would bring people (like
me) in from the sidelines to start actively using one or the other.

I like the QA aspect, too, though it's obviously not my focus. I'm
not interested in helping to build a QA repository at all. Not
because it's not a valuable thing to have, but because it doesn't fit
the kind of thing I like to do. If someone wants to lead a team to QA
(including providing patches) a bunch of apps and libraries to build a
"validated" RubyGems repository, I would both applaud it and do what I
can to support it. I'm sure the other RubyGems developers would say
the same.

--

Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)

 

[Bill Guindon]

Definitely. There has been much discussion about this. Search
ruby-talk for an exhausting several hours of reading You wouldn't
really need to even do the stable/unstable thing. It would be
possible to create a super-gem ("gems-quality-assured" or something)

Rough Gems, Polished Gems.
Seemed obvious, but I like word play.,

 

[Ben Giddings]

Definitely. There has been much discussion about this. Search
ruby-talk for an exhausting several hours of reading You wouldn't
really need to even do the stable/unstable thing. It would be
possible to create a super-gem ("gems-quality-assured" or something)
that has all of the known good versions as dependencies. That would
at least get the good ones on your system. If you _only_ installed
the super-gem, you would in effect have a full local installation of
someone's known-good list. This could be done without any changes to
RubyGems at all. What it _wouldn't_ give you is the ability to patch
the libraries, which the RPA people were doing with some of the libs
they were touching. You'd have to depend on the traditional
send-patch-and-wait method of getting patches into a library.

Except as time goes on, that list might get huge, and you might be
installing thousands of packages.

Tagging things as stable/unstable would allow you to install the stable
version of the libs you need, and not to install things you don't (yet)
need.

Anyhow, if you guys are working to make it happen, I'll prepare my happy
dance of joy.

Ben

 

[Ben Giddings]

Here's a result of a dead link check I did today.
http://raa.ruby-lang.org/announce20050304.html

As a side effect of the check, here are caches of homepage/downloadable
item.
http://raa.ruby-lang.org/cache/

WooHoo! I a not on the list of shame, on the other hand:


NG

These 506 projects have a link to unaccessible resource via open-uri.

absolut2relativ
execution expired (http://bhaak.dyndns.org/ruby/absolute2relative.html)
...
ruby
550 /pub/ruby/ruby-1.8.1.tar.gz: No such file or directory
(ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.1.tar.gz)

Ruby is on the list of shame!!!

Ben

 

[Chad Fowler]

Except as time goes on, that list might get huge, and you might be
installing thousands of packages.

I'm not really suggesting that this is a great final solution, but
it's one possible way to do it now. If we really wanted to get
serious about a QA'd gem repository, it would make sense to add
functionality for it (probably).

There's also the current capability to specify a different gem source
when doing an installation, so you could put things in a special place
and do (for example):

$ gem install -s http://qualitystuff.myserver.net somelibrary

Anyhow, if you guys are working to make it happen, I'll prepare my happy
dance of joy.

Don't dance yet, but if you're interested in helping to work to make
it happen, we'll be supportive.
--

Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)

 

[Ben Giddings]

Don't dance yet, but if you're interested in helping to work to make
it happen, we'll be supportive.

I said I was *preparing* my happy dance of joy. I haven't started doing
the dance yet. I just want to be ready. Sure, spontaneous dances of
joy are good, but a well-rehearsed one has its merits too.

I'm not sure I have time to help with this, but is it possible to get a
kind of "where we are now" summary? Are RPA and RubyGems both being
actively developed and maintained right now? Are there still features
being added to both projects? Are the two teams still actively working
togeth and sharing code?

I'm just trying to get a feel of how big a job it would be, and what
would be required to do this unification.

Ben

 

[Chad Fowler]

I said I was *preparing* my happy dance of joy. I haven't started doing
the dance yet. I just want to be ready. Sure, spontaneous dances of
joy are good, but a well-rehearsed one has its merits too.

I hope you have a digital video recorder.

I'm not sure I have time to help with this, but is it possible to get a
kind of "where we are now" summary? Are RPA and RubyGems both being
actively developed and maintained right now?

RubyGems is. I can't speak for RPA, but it seems to have gone quiet
with Mauricio's (ostensibly) temporary disappearance. It's been
nearly 4 months since the last release and I haven't seen much
packaging activity.

Are there still features
being added to both projects?

See the above.

Are the two teams still actively working
togeth and sharing code?

We had been until Mauricio got busy.

--
Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)

 

[vruz]

Do you think the different approach to packaging / format of the

packages is a matter of concern? Maybe the standard "Gem" format could
be one of a few different "renderings" of the package. That way, you
could also "render" as a .rpm or as a .deb or an RPA package.

http://rpa-base.rubyforge.org/wiki/wiki.cgi?Developer_Documentation/Native_Packages