Let's keep all client interaction there instead of the website.

Figure out why this is happening and put an end to it when accepting input.

Just do what the man said.

Handle projects that want to move over from RubyForge to Gemcutter full time.

Proposed way to do this:
Generate a token on the Rubygem model and have them upload to RubyForge, then check RubyForge for it.

It's an ugly mess, split it up, break it up into separate tasks.

http://www.jbarnette.com/2009/08/27/on-rake.html

These both could be done from one profile page, /profile perhaps.

Have a real designer revamp the site at some point.

Flesh out version one of the API, and make sure it's somewhat extensible so it can be upgraded.

Basically, toss the entire process into the background. Immediately return a HTTP 202, and then check some URI for the status until it's done.

Thinking Sphinx perhaps? No idea how to implement this yet, but should be done.

There's no way currently to do this.

Seeing this in the migration cron log:

Downloading ZenTest-3.0.0.gem...
PGError: ERROR:  value too long for type character varying(255)
: INSERT INTO "versions" ("rubyforge_project", "updated_at", "number", "description", "summary", "authors", "rubygem_id", "created_at") VALUES(E'zentest', '2009-08-08 01:02:03.171070', E'3.0.0', E'ZenTest provides 3 different tools: zentest, unit_diff, and autotest.

ZenTest scans your target and unit-test code and writes your missing
code based on simple naming rules, enabling XP at a much quicker
pace. ZenTest only works with Ruby and Test::Unit.

unit_diff is a command-line filter to diff expected results from
actual results and allow you to quickly see exactly what is wrong.

autotest is a continous testing facility meant to be used during
development. As soon as you save a file, autotest will run the
corresponding dependent tests.

There are two strategies intended for ZenTest: test conformance
auditing and rapid XP.

For auditing, ZenTest provides an excellent means of finding methods
that have slipped through the testing process. I''ve run it against my
own software and found I missed a lot in a well tested
package. Writing those tests found 4 bugs I had no idea existed.

ZenTest can also be used to evaluate generated code and execute your
tests, allowing for very rapid development of both tests and
implementation.', E'* Scans your ruby code and tests and generates missing methods for you.
* Includes a very helpful filter for Test::Unit output called unit_diff.
* Continually and intelligently test only those files you change with autotest.
* Includes a LinuxJournal article on testing with ZenTest written by Pat Eyler.', E'Ryan Davis, Eric Hodel', 20244, '2006-03-06 08:00:00.000000') RETURNING "id"

I think it would be neat to show the logged in users' gravatar. Perhaps gravatar for gem owners could be shown somewhere on gems/show too.

Definitely need some of these.

And eventually use full text search on them. This is pretty massive since it will involve downloading all 24k+ gems, which luckily is free since Gemcutter runs on Heroku, which is on EC2.

Pacecar should probably be taken out.

On the page for my vizir gem (http://gemcutter.org/gems/vizir), it says the homepage is http://github.com/priteau/vizir
It was the case in the 0.2.4 gemspec.

However the new gemspec (0.2.6) that I pushed to Rubyforge last week points to a new homepage: http://priteau.github.com/vizir/

Maybe the import code now handles this, but it would be nice if it would be corrected without having to upload a new version of the gem.

Provide some screenshots for this process and make it look decent. Also, move this into the app itself instead of the wiki.

For some reason it might be nil, so make sure to look in all the versions. Just take the most recent one we can find.

Just a simple pager is really useless.

so it's easier for people to tell what's been deployed. will also need a staging slice on heroku.

Everyone's going to have it and it's going to be less of a hassle for other Ruby implementations.

gem list -r

results in:

*** REMOTE GEMS ***
ERROR: http://gemcutter.org does not appear to be a repository ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) bad response Not Found 404 (http://gemcutter.org/yaml)

Warn the user when they're overwriting a version, add a -f flag to push to allow it.

Since we'll probably want to search and show both anyway, especially for the API.

Once there's enough space on the slice, start uploading all of the gems and get them processed.

Make sure to handle this when creating a new gem.

It would be nice to be able to hashtag your projects so you can search against this. Have the hashtags defined in the gemspec maybe?

Considering that Rubyists like to name their projects having nothing to really do with the functionality to be able to search against such tags would be valuable.

Take mongrel as example:

http://gemcutter.org/gems/mongrel

Gemcutter considers 1.1.5-x86-mingw32 as being the latest version, but that is not true. 1.1.5 is the latest version, and that version contains gems for 4 platforms:

Pure ruby
i386-mingw32
JRuby
i386-mswin32

I believe that gem platform is not being parsed properly and differently or separated of the version itself.

Just to help out for new contributors.

This definitely shouldn't happen.

Looks like pgsql doesn't do case insensitive LIKE by default, we'll have to use ILIKE instead.

specs != latest_specs, need to fix the gem index accordingly.

Ran into another issues with migrating gem from Rubyforge.

  $ gem migrate pom
  Starting migration of pom from RubyForge...
  A migration token has been created.
  Uploading the migration token to pom.rubyforge.org. Please enter your RubyForge login:
  Login:   transami
  Password:   
  There was a problem uploading your token: SCP did not finish successfully (1)
  Asking Gemcutter to verify the upload...
  Gemcutter is still looking for your migration token.

The problem is that the pom gem is not in the pom project. It is in the proutils project.

I really wish you'd just dump this migration crap, and let us push our gems without worry about legacy releases on Rubyforge.

Spin up and IRC channel and mailing list.

Perhaps the summary/description for the gem, last update, etc.

This seriously needs to be done.

Should be able to click a version link and see info for that version.

URL: /gems/[gem_name]/versions/[version_number]

Should also have a new view to list all versions:

URL: /gems/[gem_name]/versions

Should actually tell the user that their API key was saved successfully.

Perhaps consider splitting the api key transaction into a different gem command.

This way, I can be hated less for stealing gem upgrade.

Because when 2,000+ gems are on /gems/list, it'll be no fun to browse.

Should probably start an AUTHORS file too.

See what's necessary to get this working, if it's as simple as dropping in prerelease_specs into the Hostess then let's do that.

Uploading a gem returns an error message, although it shows the gem uploaded to the site afterwards (so it did work).

message:

Pushing gem to Gemcutter...
ERROR:  While executing gem ... (NoMethodError)
undefined method `strip' for nil:NilClass`

stty definitely won't work on Windows. The Heroku gem has this implemented, look at porting that over to the Gemcutter gem and testing it on a Windows machine.

Review please

http://github.com/redinger/gemcutter/commit/d519e67d0eedb5780515c1f97807b5d0d2c128a3

It just creates a new one. This shouldn't happen.

Show: # of gems, # of downloads Rubygem.sum("downloads"), and # of users.

Hopefully this will speed up gem list/installs/etc a little. Will require expiring the cache when gems are pushed.