Contributing

Fubsy is brand-new and wide open for developers to join the fun.

Source

You can get the latest source code from Fubsy's canonical Mercurial repository:

hg clone http://hg.gerg.ca/fubsy

Alternately, there's a mirror on Bitbucket:

hg clone https://bitbucket.org/gward/fubsy

Requirements

Fubsy is written in Go, which is a very nice alternative to C or C++. The good news is that it's much easier to write correct, safe, efficient code in Go than it is in C or C++. The bad news is that you may have to learn a new language to contribute to Fubsy.

See doc/build.txt in the source tree for details on Fubsy's other dependencies.

Building

The precise process varies from release to release, so see doc/build.txt in the source tree for details.

If you already have Go installed and don't care about satisfying all the optional dependencies, try:

./build.sh

Mailing list

Please join the mailing list: just send an empty message to fubsydev@librelist.org.

Submitting patches

Ground rules:

  1. Don't break the build. The entire project must build and pass all tests after every patch.

  2. One change per patch. If you need to refactor a bit in order to add a feature, that's two patches. If you have fixes for three bugs, that's three patches.

  3. Keep it focused:

    • don't throw in "trivial" bug fixes as part of a larger change
    • don't include unrelated whitespace changes
    • don't include unrelated/unnecessary refactoring

    All of those changes are welcome, but as separate patches.

  4. Keep test coverage up.

    • If you're fixing a bug, that means the unit tests missed something. Please try to add a unit test that fails without your fix, and passes with it.
    • If you're adding a feature, add unit tests.

    (Patches that add unit tests purely to increase coverage are always welcome!)

You can submit patches using email or as pull requests on Bitbucket.

Emailing patches (low tech)

Feel free to generate small, simple changes the old-fashioned way:

hg diff > my-change.patch

and then email my-change.patch to fubsydev@librelist.org with a clear explanatory message.

(An advantage of this method is that you can evolve your patch after review without using any fancy mutable history tools.)

Emailing patches (high tech)

Alternately, you can commit to your local Mercurial clone and then use the patchbomb extension to email your changes. First, you have to configure patchbomb. The full documentation is in Mercurial's wiki, but here's the short version:

$ cat >> .hg/hgrc
[extensions]
patchbomb =

[email]
from = Your Name <you@example.org>
to = fubsydev@librelist.org

You also need to tell Mercurial how to send email (sendmail or SMTP): see the patchbomb wiki page.

Once that one-time setup is done, you can send patches by running

hg email -r REV

or

hg email -r REV1:REV2

Pull requests

Pull requests are more appropriate for patches that have been through some review and are more-or-less approved. They're also fine for trivial or "obviously correct" changes... although your definition of obvious may not be mine.

To submit a pull request, you'll have to make a clone of Fubsy's Bitbucket repository, push to that clone, and then submit the request.

Author: Greg Ward
Published on: Dec 12, 2012, 9:25:01 AM - Modified on: Jan 23, 2013, 2:15:51 PM
Permalink - Source code