Skip to content

Contribution Guidelines

Jump to bottom
zenom edited this page Oct 10, 2010 · 40 revisions

From the Rubinius contribution page:

Writing code and participating should be fun, not an exercise in perseverance. Stringent commit polices, for whatever their other qualities may bring, also mean longer turnaround times.

Submit a patch and once it’s accepted, you’ll get commit access to the repository. Feel free to fork the repository and send a pull request, once it’s merged in you’ll get added. If not, feel free to bug qrush about it.

Also, if you’re hacking on Gemcutter, hop in #gemcutter on irc.freenode.net! Chances are some else will be around to answer questions or bounce ideas off of.

How To Contribute

  • Fork the project
  • Create a topic branch for what you’re working on (git checkout -b awesome_feature)
  • Commit away, push that up (git push your_remote awesome_feature)
  • Create a Pull Request for the commit, asking for review.
  • Once it’s accepted, if you want access to the core repository feel free to ask! Otherwise, you can continue to hack away in your own fork.

If you’re looking for things to hack on, please check GitHub Issues. If you’ve found bugs or have feature ideas don’t be afraid to pipe up and ask the mailing list or IRC channel (#gemcutter on irc.freenode.net) about them.

Setup

Some things you’ll need to do in order to get this project up and running:

  • Install bundler: gem install bundler
  • Install redis, version 2.0 or higher. If you have homebrew, do brew install redis -H.
  • Move into your cloned gemcutter directory if you haven’t already: cd path_to_clone
  • Gemcutter is configured to use PostgreSQL, for MySQL see below.
  • Install test dependencies: bundle install vendor/bundler_gems
  • Setup a database.yml cp config/database.yml.example config/database.yml (double check/update)
  • Create the databases: rake db:create:all
  • Run redis-server.
  • Update the db schema: rake db:migrate
  • Run the tests: rake

Make sure you run rake gemcutter:index:update before running the app on your own machine, this primes the filesystem gem index for local use.

MySQL

  • Modify Gemfile to use mysql instead of pg
  • If you’re running Max OS X Snow Leopard, the MySQL gem will fail to install without configuring it as follows:
bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
export ARCHFLAGS="-arch x86_64"
  • Continue setup as above, installing dependencies, setting up database.yml, etc.

Gem

For testing/developing the gem, cd into the gem directory. Please keep the code for the gem in there, don’t let it leak out into the Rails app.

In order to push a gem to your local installation use a command like the following

RUBYGEMS_HOST=http://localhost:3000 gem push hola-0.0.3.gem

Getting some test data

A good way to get some test data is to import from a local gem directory. gem env will tell you where rubygems stores your gems. Run rake gemcutter:import:process #{INSTALLATION_DIRECTORY}/cache

If you see “Processing 0 gems…” you’ve probably specified the wrong directory. The proper directory will be full of .gem files.

Acceptance

Contributions WILL NOT be accepted without tests. If it’s a brand new feature, you should have a Cucumber scenario (or several!) as well. If you haven’t tested before, start reading up in the test/ directory to see what’s going on. If you’ve got good links regarding TDD or testing in general feel free to add them here!

Branching

For your own development, use the topic branches. Basically, cut each feature into its own branch and send pull requests based off those. On the main repo, branches are used as follows:

Branch Used for…
master The main development branch. Always should be fast-forwardable.
staging Whatever’s currently on http://staging.rubygems.org. Can be moved around as needed to test out new features/fixes. If you want to test out your changes on our staging server, bug qrush and you can play around there.
production What’s currently on http://gemcutter.org. Should be updated when deploys happen from master with git push origin master:production
Topic branches Individual features/fixes. These should be moved around/rebased on top of the latest master before submitting. Make your patches easier to merge and keep the history clean if at all possible.
Clone this wiki locally