Tarantool Developer Guide


What documentation there is
1. Compiling
How to fix a compile time error about missing confetti
How to build the XML manual
2. Release management
How to make a minor release
3. Developer guidelines
How to work on a bug

What documentation there is

Tarantool documentation consists of:

  • a user guide

  • a developer guide (you're reading it)

  • protocol description box-protocol.txt

  • coding style guides for Lua, Objective C, C, Python (for other connectors, we use conventions of the connector programming language community)

Chapter 1. Compiling

How to fix a compile time error about missing confetti

An error about missing confetti:

Generating prscfg.h, prscfg.c...
[ 13%] Generating prscfg.h, prscfg.c
/bin/sh: CONFETTI-NOTFOUND: not found

This error is caused by cmake, trying to re-create generated files prscfg.h, prscfg.c in cfg/ directory. These files are under revision control and normally need not to be regenerated. The fix is to

$ git checkout cfg/prscfg.h
$ git checkout cfg/prscfg.c
$ touch cfg/prscfg.[hc]

The other alternative, if you have actually modified core_cfg.cfg_tmpl is to install confetti from http://github.com/mailru/confetti and let cmake use it.

How to build the XML manual

To build XML manual, you'll need:

  • xsltproc

  • docbook5-xml

  • docbook-xsl-ns

  • w3c-sgml-lib

  • libsaxon-java- for saxon processing

  • libxml-commons-resolver1.1-java

  • libxml2-utils

  • libxerces2-java

  • libxslthl-java

  • lynx

  • jing

When all pre-requisites are met, you should run:

  $  cmake . -DENABLE_DOC=yes

to enable documentation builder. If you want to make tarantool user guide, you should run the following command from taratnool root directory:

  $  make html

or

  $  cd doc/user
  $  make

The html version of the user guide will be generated in doc/www-data. To building the developer guilde, you should run:

  $  cd doc/developer
  $  make

The html version of the developer guide will be generated in doc/www-data.

Chapter 2. Release management

How to make a minor release

git tag -a 1.4.4 -m "Next minor in 1.4 series"
vim CMakeLists.txt # edit CPACK_PACKAGE_VERSION_PATCH
git push --tags

Update the Web site in doc/www-data.

Go to launchpad and move all "Fix committed" bugs to "Fix released".

Update all blueprints, upload the ChangeLog, based on git logoutput. The ChangeLog must only include items which are mentioned as bugs or blueprints on Launchpad. If anything significant is there, which is not mentioned, something went wrong in release planning and the release should be held up until this is cleared.

Click 'Release milestone'. Create a milestone for the next minor release. Alert the driver to target bugs and blueprints to the new milestone.

Upload the milestone from http://tarantool.org/dist to Launchpad. Use the .src.tar.gz build.

Chapter 3. Developer guidelines

How to work on a bug

Any defect, even minor, if it changes the user-visible server behavior, needs a bug report. Report a bug at http://bugs.launchpad.net/tarantool. When reporting a bug, try to come up with a test case right away. Set the current maintenance milestone for the bug fix, and specify the series. Assign the bug to yourself. Put the status to 'In progress' Once the patch is ready, put the bug the bug to 'In review' and solicit a review for the fix.

Once there is a positive code review, push the patch and set the status to 'Fix committed'

Patches for bugs should contain a reference to the respective Launchpad bug page or at least bug id. Each patch should have a test, unless coming up with one is difficult in the current framework, in which case QA should be alerted.

There are two things you need to do when your patch makes it into the master:

  • put the bug to 'fix committed',

  • delete the remote branch.