Re: RPA and author packages/interactions (forward vision)

On Friday 29 October 2004 19:03, Eivind Eklund wrote:
> Discussions of the full RPA at the bottom.

Wow.. this is good insight into how RPA works.


[snip]
> 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 think its good with competition between the RPA team and the GEMs team.
It results in faster development (suvival of the fittest). What I like is that 
both teams follows two distinct goals, only with little overlap.
Sharing code and specs is good.


[snip]
> > 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.  

This seems to me as a very wise choice.


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

How far is RPA from reaching this point?


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

The quality of Ruby is good.. This makes people aim for better quality than if
they were stuck with C++.  Same with RPA.


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

AFAIK RPA is already pretty mature.. Im wondering why you say 'incomplete'?


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

Ah.. so when a package is first released then its just a .gem, and later
when its RPAfied.. it becomes an real rpa package.
This is nice.


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

ok


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

One thing that I find frustrating when installing a program, and I want to
report a bug or a feature.. that some projects doesn't have homepages,
nor valid mail adresses (though I haven't yet seen ruby projects like this).
It would be nice if there were a uniform way to report bugs, submit feature 
requests and contact the package authors.

Mozilla can send crash-info automaticly to the mozilla-bug database.
Something similar could be useful too.


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

ok


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

sweet music in my eye.


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

Maybe it could be useful to know your reasons, why you have
chosen DARCS over subversion over CVS.
Im not that much into version control.. but I am curious to your reasons.


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

I am strongly considering to become an RPA porter/committer.

--
Simon Strandgaard