Development/Workflow

Development Workflow

Common workflow

The usual workflow we use to add features is the following:

  1. Grab the code by cloning one of the repos (usually the mainline one).
  2. Code/fix something following the [browser/devel-docs/CodingStyle guidelines].
  3. Write unit tests for each feature/bug.
  4. Run make test to make sure the new code didn't bring any regressions.
  5. Commit.
  6. Repeat 2-4 often (small features, often commits). Pull often to make sure merging is OK.
  7. Once it's ready, let us know (eg. directly email the changeset to the mailing list (hg email), bundle it (hg bundle) and send the email manually, or push it to a public repo of yours and let the group know).
  8. Someone will review the changes and push them in the main repo.

For a public hg hosting service, take a look at bitbucket or freehg.

Coding style

See devel-docs/CodingStyle.

Discussing development

The development discussion group is transifex-devel. To receive updates on code checkins and ticket modifications, subscribe to the transifex-updates group, which you can use to comment on the development.

Mercurial Setup

Name and email

Setup a name and an email address, and some common locations.

~/.hgrc:

[ui]
username = A Contributor <contributor@example.com>

[paths]
txo=http://code.transifex.org/transifex/

Extensions

You can enable some pretty useful extensions:

  • hgk: hg view opens a nice graphical history tree.
  • graphlog: hg glog is an enhanced hg log that displays the history tree using asciiart.
  • patchbomb: you can send patches with hg email command.
  • extdiff: use an external program to view diffs (eg. hg extdiff -p /usr/bin/meld)
~/.hgrc:

[extensions]
hgext.hgk=
hgext.graphlog=
hgext.patchbomb=
hgext.extdiff=

Setup patch sending

The patchbomb extension enables sending patchsets via email. You have to setup some information to the global hgrc file.

~/.hgrc:

[email]
method = smtp
from = A Contributor <contributor@example.com>
cc = Transifex devel list <transifex-devel@googlegroups.com>

[smtp]
host = smtp.gmail.com
tls = true
username = <your username>
password = <your password>

You can now send a patch/patchset with:

  • patch: hg email --inline --diffstat --to a-maintainer@transifex.org --rev tip
  • patchset: hg email --inline --diffstat --to a-maintainer@transifex.org --rev 250:252

To import a patchset, save the file somewhere on your system and use hg import to add the changesets in a tree of yours. This will have the same effect as running hg pull from a repo with those patchsets.

Colored diffs

To produce colored diffs, you can install the 'colordiff' package and configure hg to use it.

~/.hgrc:

[defaults]
# suppress noisy extdiff header message
cdiff = -q

[extdiff]
cmd.cdiff = colordiff
opts.cdiff = -uprN

Simple patch sending

Once you fix something, you can send a simple patch to the maintainer or the mailing list. Even better, you can commit the patch and send the committed one. The latter is preferred, as your name will appear in the commit message and the maintainer can more easily import your patch.

To do so, setup your name in ~/.hgrc as descibed in #Nameandemail. Then commit your fix and package it in a 'bundle', as follows:

hg clone ...
(fix something)
hg commit -m 'bugfix: Foo should be bar and not baz'
hg bundle mycommit.bundle

Attach the bundle on an email and send it to a maintainer, CCing the list. He'll be able to simply run hg import and your commit will be implanted in his repository.