Develoment model (using "git").

Basic policy has been agreed on in this thread:
  http://markmail.org/message/7lnus64entdwj4vo

Additions are in order if and when handling of legacy code is decided.

doc/development/development.howto.txt

@@ -0,0 +1,23 @@
+This document summarizes a discussion that took place on the "dev" ML:
+  http://markmail.org/message/7lnus64entdwj4vo
+
+The conclusions reported here are based on ideas presented in this blog post:
+  http://nvie.com/posts/a-successful-git-branching-model/
+
+1. The "master" branch can only contain released code; i.e. the only
+   accepted commits are the result of a merge from the "release" branch
+   (from a release candidate that passed a vote).
+2. Contents that is candidate for being released must be merged into the
+   "release" branch, from the "development" branch.
+3. The "development" branch collects all modifications that will be part
+   of the next release.
+   Usually, changes should not be committed directly to the "development"
+   branch; they should be merged from a branch specifically created for
+   that purpose (see next point).
+4. Work on an identified issue (bug fix or new feature) must be done in a
+   new branch named after its corresponding report in the bug-tracking
+   system (JIRA), e.g. "feature-MATH-1319".
+   After completion, and in the absence of technical objections, the feature
+   branch is merged into the "development" branch, using the "--no-ff" git
+   option.
+   That feature branch is then deleted.