Skip to content

Instantly share code, notes, and snippets.

@zerebubuth
Created February 13, 2012 14:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save zerebubuth/1817398 to your computer and use it in GitHub Desktop.
Save zerebubuth/1817398 to your computer and use it in GitHub Desktop.
Draft new README

Description

This is the Rails port, the Ruby on Rails application that powers OpenStreetMap.

Something more about what the rails port is for here...

Running it

You can find documentation on how to setup and run the software on the OpenStreetMap wiki.

Hacking it

The canonical Git repository for this software is hosted at git.openstreetmap.org, but much of the development is done on GitHub.

Testing

Having a good suite of tests is very important to the stability and maintainability of any code base. The tests in the Rails port code are by no means complete, but they are extensive, and must continue to be so with any new functionality which is written. Tests are also useful in giving others confidence in the code you've written, and can greatly speed up the process of merging in new code.

When hacking, you should:

  • Write new tests to cover the new functionality you've added.
  • Where appropriate, modify existing tests to reflect new or changed functionality.
  • Never comment out or remove a test just because it doesn't pass.

Comments

Sometimes it's not apparent from the code itself what it does, or, more importantly, why it does that. Good comments help your fellow developers to read the code and satisfy themselves that it's doing the right thing.

When hacking, you should:

  • Comment your code - don't go overboard, but explain the bits which might be difficult to understand what the code does, why it does it and why it should be the way it is.
  • Check existing comments to ensure that they are not misleading.

Appropriate patches

When you submit patches, the project maintainer has to read them and understand them. This is difficult enough at the best of times, and misunderstanding patches can lead to them being more difficult to merge. To help wit this, when submitting you should:

  • Split up large patches into smaller units of functionality.
  • Keep your commit messages relevant to the changes in each individual unit.

Sending the patches

See commiting to the rails port on the wiki for getting your patches integrated:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment