On Fri, 13 Aug 2004 23:00:25 +0900, vruz <horacio.lopez / gmail.com> wrote:
> > Same point as above, rpa could provide those advantage as a layer over
> > rubygems without having to reinvent the distribution layer.
> 
> Please count the lines of code Mauricio Fernandez has kindly
> provided to the Rubygems project.
> (if that's possible, not sure who applied the code on behalf of him,
> or under which user account he did that)
> 

I was going to make this point.  It's kind of ridiculous to go
counting lines, but Mauricio provided a (not-yet-released) patch to
change the gem format to be tar/gz.  That was indeed very helpful and
significant in size.


> Add other patches Mauricio Fernandez has provided to the Rubygems
> team, but were (quickly) dismissed,  and  later reimplemented by
> the Rubygems team.
> 

I think you're exaggerating here.  I know of one patch that was the
subject of literally weeks of debate.  What got implemented was based
on Mauricio's proposal but the functionality didn't match what we were
after exactly, so it was implemented from scratch.

> Compare this number to the total lines of code in Ruybgems.
> 

We welcome more.  As I said, the code we've gotten from rpa-base is
great.   We've also had a ton of contributions from many other members
of the community that have vastly improved the RubyGems code and
functionality.

> The fact that a given person opts to have a low-profile personality
> and tries not to offend a team of professional programmers by
> patching a great deal of the code they have wrote,  is not IMHO
> a valid reason why  he should submit himself to the guidelines
> and  work processes of a given project.
> 

None of us would be offended by patches.  A lot of the code in
RubyGems now has been  completely refactored/replaced by "new" people
since it was originally created at RubyConf.  This is the way open
source works.  It's good.

This is not to say that we're always going to agree with every patch
that anyone sends in.  It's fairly democratic.  If you have an opinion
about something that should change in RubyGems, join the list and
bring it up.  We're closing in on feature completion for 1.0, so it's
probably a good time.

> To my knowledge, Rubygems is not a blessed standard as it still claims
> to be, and it's a rather uncomfortable practice within an open-source
> community when people try to impose something that clearly doesn't
> fit their purposes, interests, likes or dislikes.
> 

RubyGems was created to fill a huge hole in the community: a
"standard" way to package, publish, discover, install, uninstall, and
manage Ruby libraries.  The lack thereof has been a common complaint
since I started using Ruby years ago (and probably before then).  A
group of us at last year's RubyConf decided enough was enough and we
were going to do something about it.

As for the use of the word "standard",  this is the project's goal. 
Whether it be defacto or blessed, the Ruby community (particularly new
users) needs a "standard" way to find and install libraries.  That
doesn't mean there can't be other ways.  It also doesn't mean the
standard can't change.  Redhat users can use rpm/yum, which comes on
with their OS, or they can switch to apt-get/dpkg.   If *one* of these
packaging systems doesn't become at least a defacto standard, it
wasn't worth our effort.


> Believe me I love good engineering, and I hate effort duplication.
> 
> But I love free speech more.
> 

Me too.  I don't think anyone's trying to suppress it here.

It would be interesting for Mauricio to chime in here.  Whenever I
speak to him about RPA, he affirms that RPA and RubyGems are not meant
to compete.  Most of the posts in this thread are about competition. 
I feel like there is room for both.  RubyGems is meant to be an
augmentation of RAA, with a great deal of freedom.  RPA is a
replacement for RAA, with a stringent QA and release process.  Not
only is there room for both, but I think they can feed each other
nicely (in code sharing, process improvement, and overall quality
improvement).

Chad