Discussions of the full RPA at the bottom.

On Fri, 29 Oct 2004 14:48:59 +0900, GGarramuno <ggarramuno / aol.com> wrote:
> >
> >Then it sounds like that RubyGems needs to adopt the framework of RPA, and
> >help improve/adapt it to its needs, e.g. versionsing.
> >
> >I like RPA. I want to use RPA. But I can't. I have to say "pretty please"
> >package this for me. I understand the QA. I think that's great. But I also
> >think there needs be a way for beta wares to "get on the line". Gems allows
> >that. So I'll just use Gems.
> 
> Amen, brother.
> 
> From trying both, my impression so far (which does not yet include evaluation
> of how C modules are handled) is that rpa is clearly superior for my needs.
> 
> But, as well intentioned as rpa's team may be, not having a well 
> documented and clean way to distribute your own packages, I see it never 
> catching on.

We're crawling two paths towards this: Helping RubyGems with their
commitment to being repacker friendly (at which point we can easily
provide the RubyGems "package API", so you can use .gem's from the RPA
tools), and looking at an experimental section.  The latter would
allow authors to hook the same infrastructure we do, and allow authors
to reasonably quickly get "integrated with the team".  With that,
they'll either maintain their own packages by having write access to
the main branch, or feel comfortable that they are better off with
having somebody else do that for them.

I'll try to describe the sociotechnical interactions in this a bit better below.

> Mauricio, that web page explaining things really does not explain anything.
> Icould not make head or tails of it.  Having perhaps the rpa "gemspec" 
> available for the modules of rpa would be a better approach.
[...]
> If RPA's format was documented and was as simple to use as a gemspec 
> (or, better yet, use gemspec itself as it stands, as it is popular enough 
> already), I really would not bother with rubygems, imo.

The RPA format is simpler/cleaner than the corresponding gemspec,
usually.  However, we prefer to have the RPA format only used in the
RPA repository, in order to be able to change it and do updates across
all packages.  With the RubyGems commitment to becoming repackager
friendly (and we try to give as much help as we can with that),  we
hope that using the RubyGems format for external author-packaged
packages and the RPA format for RPAfied packages (with their extra
requirements) will give an ideal result.  Of course, for end user
convenience, these will need to be available through the same user
interface.


I've previously tried to outline what I'd like RPA to be in terms of
quality etc, in the form of the RPA manifesto and other writings. 
What I've not shared with anybody beyond musing about it on IRC,
however, is how achieve this,.and how I see the interactions between
RPA and authors when RPA is "fully functional".

Please understand that what I describe here is necessarily incomplete,
and that we'll have to get there one step at a time.  We will also
modify the plan as we gain experience from the steps we take, and as
we get feedback from people using it.

First, let's look at this from the perspective of a developer that
does not use the RPA infrastructure directly.

When he has a release ready, he'll just put out a .gem.  The Usual
Processes will catch the gem and add it to the gem list.  At this
point, it's easily available through RPA interface too, and install
will integrate with RPA.  However, some of the RPA features will not
be available for that (because various metadata and setup is missing
compared to a RPAfied package), and the user will be warned about this
and the lack of quality control.

A little while later (hours to days) the RPAfied source variant of the
package (the port update) will appear in the HEAD of RPA.  This will
just require minimal testing; standard difference review from the last
release, testing that it package correctly on at least one platform
(more if we have suitable automation), checking for correct internal
version numbering if a library, and other small QA work.  For a core
package (one that we have blessed as being "production quality and
maintained from RPA"), there will be somewhat more extensive QA for
updates.  We'll probably also use various test branches etc to
streamline this process.

There will also appear various mail aliases, a bug tracker, etc on the
RPA site, but these are the responsibility of the porter (RPA person)
rather than the original author.  The standard procedure is to notify
the original author about these lists and of course allow her to take
some level of control of how they work (automatically gating to other
lists if wanted, etc), but RPA will make sure the well-known list
names are there for every package.

As maintenance is done through RPA, the porter will act as a liason to
the author, ensuring that the author get hold of new patches and
relevant bug reports, and trying to screen out the rest, giving a
"maximally relevant" feed to the author (controlled by the preferences
of the author).

One of the problems with most packaging systems is that they distance
the user from the code.  Getting a program from the archive into a
form where it is easy to hack on is noticeable amounts of work; often,
it involves going totally outside the archive and checking code out
from some unknown CVS repository somewhere, and using "some weird
unknown build/install procedure".  We want RPA to do the opposite:
Make the distance from the package to being an active  project
contributor on the code and/or documentation level *smaller* than it
is when starting from an author release.  To help this, we'll try to 
normalize the development environment.

To start working on a package, do 'rpa hack <portname>', and get a
checked out version of the port with version control metadata for a
distributed VC (at the moment it looks like we'll use DARCS, but we're
not quite sure.  CVS does not work at all well for this task.)  With
this, it will also be easy to give your changes back to RPA - probably
just 'rpa offer' from the workspace, or something like that.  (We'll
look at the exact user interface later.)

To get started with the software in it, look at the RPA_HACKING file
in that directory.  It will be what notes the code review team of RPA
has made about that package, using our standard terminology etc (we'll
try to keep the style reasonably consistent.)

To get on the mailing list for the people working on that software
through RPA, using the mail aliases described above, use 'rpa
subscribe dev <package name>'

For an author that want to work more closely with RPA: You can just
hook yourself onto the infrastructure described above, initially
working in a sandbox branch, later becoming your own porter.  You'll
get "free merges" to the software from other RPA committers/porters -
added test coverage, fixed documentation, etc.

Eivind.
-- 
Hazzle free packages for Ruby?
RPA is available from http://www.rubyarchive.org/