chore: update branching conventions in /doc

doc/development/development.howto.txt

@@ -1,5 +1,6 @@
 This document summarizes a discussion that took place on the "dev" ML:
-  http://markmail.org/message/7lnus64entdwj4vo
+  http://markmail.org/message/7lnus64entdwj4vo and
+  http://markmail.org/message/3xjj2g74ga4iyijg
 
 The conclusions reported here are based on ideas presented in this blog post:
   http://nvie.com/posts/a-successful-git-branching-model/
@@ -8,16 +9,16 @@ The conclusions reported here are based on ideas presented in this blog post:
    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 "develop" branch.
-3. The "develop" branch collects all modifications that will be part
+   "release" branch, from the "master" branch.
+3. The "master" branch collects all modifications that will be part
    of the next release.
-   Usually, changes should not be committed directly to the "develop"
+   Usually, changes should not be committed directly to the "master"
    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 "develop" branch, using the "--no-ff" git
+   branch is merged into the "master" branch, using the "--no-ff" git
    option.
-   That feature branch is then deleted.
+   That feature branch is then deleted.