From: Aredridel <aredridel@...>
Date: 2004-11-23T03:26:11+09:00
Subject: Re: RPA vs rubygems (Re: [ANN] postgres-pr (pure Ruby PostgreSQL))

> > Ruby library writers, which one do you prefer or do you find easier to
> > package your software with?
> 
> In general, they should package using RubyGems or Aoki's setup.rb.
> RPA packages are created by the RPA crew: the upstream developer needs
> not do anything.

I'd like to pipe up here: I'm often around (#RPA on freenode) to talk
about packaging issue and production issues. Part of the idea is that
it takes some outside involvement to make a good package, to make sure
that things don't collide when loaded at the same time, making install
(and uninstall!) is 100% flawless; making sure that there's nothing
brittle that's likely to break by accident in the distribution.

It takes a lot to make a package production-quality (And I mean the
sort of production like, say, a bank might want for doing transaction
processing; known reliable software that has been tested as well as
checked over for accuracy). Library authors get about 90% of it
themselves, sometimes more. Then there's the things that only happen
when, you say, try to install a new package on ruby 1.6 on an HP/UX
machine, or say, fail to work reliably due to NFS locking issues;
those things take community testing to find.

RPA shies away from having people package their own work, because to
make a coherent system, a human double-check is really nice. In
non-trivial systems, issues come up. If we find some, we'll work with
the author on it. The idea is to get packages up to production quality
for the archive -- since maintenance is an issue, it implies that
getting the author to fix the problem or at least merge a fix into
their own source is the best way. If that's not possible, then the
package gets patched as it's committed to RPA.

The real goal, though, is to make ruby packages in general reliable.
rpa-base, the package manager, is just one way to accomodate that.

Software direct from author to user is great for the bleeding edge.
The early adopter crowd is willing (and in fact enjoys) the challenge
of working with the shifting sands of software. Other businesses won't
commit to something until it's been tested by others, until there's
some guarantee that they can rely on it without it changing beneath
them, that bugs will be fixed without being tied to incompatible API
changes, and that new features will be added on a strictly
won't-break-anything basis.  There's room and a need for both in this
world.