commit 3b6752514bdf9a240b89b935f15b0f68511f4a99
parent 50cef203ba59380a80561a29be48288b1777174c
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 12 Aug 2022 07:21:31 +0200
add back from texi
Diffstat:
1 file changed, 107 insertions(+), 4 deletions(-)
diff --git a/man_developers/style.rst b/man_developers/style.rst
@@ -1,7 +1,7 @@
-******************
-Style Guide
-******************
+*******************
+Style and Workflow
+*******************
This document contains normative rules for writing GNUnet
code and naming conventions used throughout the project.
@@ -149,4 +149,107 @@ Note that :c:`char *` is different from :c:`const char*` and
:c:`int` is different from :c:`unsigned int` or :c:`uint32_t`.
Each variable type should be chosen with care.
-.. code-block:: c
+
+.. todo:: There is still a chunk missing here from the old docs!
+
+
+Continuous integration
+~~~~~~~~~~~~~~~~~~~~~~
+
+The continuous integration buildbot can be found at
+https://buildbot.gnunet.org. Repositories need to be enabled by a
+buildbot admin in order to participate in the builds.
+
+The buildbot can be configured to process scripts in your repository
+root under ``.buildbot/``:
+
+The files ``build.sh``, ``install.sh`` and ``test.sh`` are executed in
+order if present. If you want a specific worker to behave differently,
+you can provide a worker specific script, e.g. ``myworker_build.sh``. In
+this case, the generic step will not be executed.
+
+For the ``gnunet.git`` repository, you may use \"!tarball\" or
+\"!coverity\" in your commit messages. \"!tarball\" will trigger a
+``make dist`` of the gnunet source and verify that it can be compiled.
+The artifact will then be published to
+https://buildbot.gnunet.org/artifacts. This is a good way to create a
+tarball for a release as it verifies the build on another machine.
+
+The \"!coverity\" trigger will trigger a coverity build and submit the
+results for analysis to coverity: https://scan.coverity.com/. Only
+developers with accounts for the GNUnet project on coverity.com are able
+to see the analysis results.
+
+Commit messages and developer branches
+.. _Commit-messages-and-developer-branches:
+
+Commit messages and developer branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can find the GNUnet project repositories at https://git.gnunet.org.
+For each release, the ChangeLog file is generated from the commit
+history. Hence, commit messages are required to convey what changes were
+made in a self-contained fashion. Commit messages such as \"fix\" or
+\"cleanup\" are not acceptable. You commit message should ideally start
+with the subsystem name and be followed by a succinct description of the
+change. Where applicable a reference to a bug number in the bugtracker
+may also be included. Example:
+
+.. code-block:: text
+
+ # <subsystem>: <description>. (#XXXX)
+ IDENTITY: Fix wrong key construction for anonymous ECDSA identity. (Fixes #12344)
+
+If you need to commit a minor fix you may prefix the commit message with
+a dash. It will then be ignored when generating the ChangeLog entries:
+
+.. code-block:: text
+
+ # -<text>
+ -fix
+
+If you need to modify a commit you can do so using:
+
+.. code-block:: console
+
+ $ git commit --amend
+
+If you need to modify a number of successive commits you will have to
+rebase and squash. Note that most branches are protected. This means
+that you can only fix commits as long as they are not pushed. You can
+only modify pushed commits in your own developer branches.
+
+A developer branch is a branch which matches a developer-specific
+prefix. As a developer with git access, you should have a git username.
+If you do not know it, please ask an admin. A developer branch has the
+format:
+
+::
+
+ dev/<username>/<branchname>
+
+Assuming the developer with username \"jdoe\" wants to create a new
+branch for an i18n fix, the branch name could be:
+
+::
+
+ dev/jdoe/i18n_fx
+
+The developer will be able to force push to and delete branches under
+his prefix. It is highly recommended to work in your own developer
+branches. Code which conforms to the commit message guidelines and
+coding style, is tested and builds may be merged to the master branch.
+Preferably, you would then\...
+
+- \...squash your commits,
+
+- rebase to master and then
+
+- merge your branch.
+
+- (optional) Delete the branch.
+
+In general, you may want to follow the rule \"commit often, push tidy\":
+You can create smaller, succinct commits with limited meaning on the
+commit messages. In the end and before you push or merge your branch,
+you can then squash the commits or rename them.
