Codefest Grant - RubyGems cleanup and enhancement

[Richard Lyman]

I think Ryan is just asking everyone, in his own sweet way, to "STFU"
about comparisons between RPA and RubyGems because *that* discussion
is completely off-topic for the originally stated purpose of *this*
thread (namely, Eric's question: "What you want to see cleaned up or
enhanced in RubyGems?").

I don't believe that anyone is opposed to the development of a GUI
front-end to RubyGems, but it may be (in Ryan's estimation) too large
of a project for the guys to try to tackle in one weekend, considering
all of the other possible "cleanups" that likely need to be done.

That makes more sense. Thanks!

-Rich

 

[Eric Hodel]

--Apple-Mail-22--516345876
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

I'm confused. _What_ goes for writing a whole GUI frontend?

Not going to happen.

You're going to write a frontend for 'gems'?
No.

The _first_ release
should be entirely possible in one weekend with a couple of good
developers.

Exactly. The Codefest Grant is enough for one weekend, so what's the
purpose of spending money on us if what we develop is unlikely to be
maintained or finished? (I'm not terribly interested in maintaining
it, and I'm certainly not interested in GUI toolkit headaches either.)

I'd much rather see the Codefest Grant money put to a use that will
have the greatest benefit to Ruby, and a GUI only falls under the "ooh!
shiny!" category for me.

Things like behaving nicely to ^C or a command to remove old gems are
much more beneficial and I think the community will get more value for
their donated dollars. We're looking for the rough edges and dull
surfaces to sand down and polish. (Yeah, I'm going to be spending your
money, so I don't want to be producing stillborn projects.)

The idea is to pull off a huge success so we (the community) can point
to something and say "look what your donated dollars bought!" This way
more dollars will be donated which allows larger, longer projects to be
funded.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-22--516345876
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCN4U4MypVHHlsnwQRApS5AJ9B2OjCJkpWzkXP7AbSfVHjN9iDXgCguFto
MkGdoAX8SG15p76Q1d6A0kU=
=yU3/
-----END PGP SIGNATURE-----

--Apple-Mail-22--516345876--

 

[Douglas Livingstone]

RPA doesn't
care too much about the package format, it's more focused on the
process, and making sure that there are consistent, documented libraries
that are production-ready (that's what your manifesto says anyhow).
This is like how the FreeBSD ports system works (or so I understand).
The packages are audited, repositories are maintained, etc. RubyGems on
the other hand *seems* to be an attempt to create a package format, a
repository and a basic package manager, with new features added as they
become necessary. This is like the rpm package format and the rpm
commandline tool. On the other hand, there's no attempt made to see if
a given foo.rpm is any good.

Both sides have the *same* goal: Get code from the writers to the users.

The methods remind me of the "Worse Is Better" concept:
http://www.dreamsongs.com/WorseIsBetter.html

Here we have RubyGems as "Worse" and RPA as the "Right Thing"...
someone just needs to point out that they are trying to do the same
thing: get the best Ruby code out to the people who want it. It is
just that one side talks about manifestos and the other talks about
purpose, beyond that they have the same goal.

The methods are just different..

Douglas

 

[Richard Lyman]

Not going to happen.


Exactly. The Codefest Grant is enough for one weekend, so what's the
purpose of spending money on us if what we develop is unlikely to be
maintained or finished? (I'm not terribly interested in maintaining
it, and I'm certainly not interested in GUI toolkit headaches either.)

I'd much rather see the Codefest Grant money put to a use that will
have the greatest benefit to Ruby, and a GUI only falls under the "ooh!
shiny!" category for me.

Things like behaving nicely to ^C or a command to remove old gems are
much more beneficial and I think the community will get more value for
their donated dollars. We're looking for the rough edges and dull
surfaces to sand down and polish. (Yeah, I'm going to be spending your
money, so I don't want to be producing stillborn projects.)

The idea is to pull off a huge success so we (the community) can point
to something and say "look what your donated dollars bought!" This way
more dollars will be donated which allows larger, longer projects to be
funded.

That makes perfect sense then. Thanks for the explanation and good
luck with the enhancements!

-Rich

 

[gsinclair]

Ben, I reckon the best way to handle 'stable' and 'unstable' is to have
a website dedicated to Ruby packages (like an improved RAA; I know
that's been discussed recently). Allow user reviews, tie it in with
Rubyforge and RAA, allow categorisation as stable or unstable, etc.

Then people can browse the information as they please, and the 'gem'
command-line app can take advantage of the information as well (through
a web service or DRb or whatever).

It's crucial to keep the data separate from the metadata, IMO.

Cheers,
Gavin

 

[Yukihiro Matsumoto]

Hi,

In message "Re: RubyGems, RPA and best tool for the job"

|> I'd happy to merge the packaging system (with
|> which both teams can agree) in the standard Ruby.
|
|They already have. But it seems to me that Matz feels we need to
|converge on a common format (between RubyGems and RPA). We don't. I
|propose that we already "agree" to the necessary level. We have
|totally different goals, with some confusing implementation overlap.

I just don't want to discourage one side by merging another. If RPA
camp say "OK, we go our way, nevertheless Gems merged in the
distribution", that's fine for me. Did they?

matz.

 

[Martin DeMello]

Thanks! I was too lazy to 'm-w.com' it.

'populous' is a word in its own right, so m-w.com wouldn't have been too
helpful

martin