commit eab35d514e2d1307f992d288e8ab817874207e42
parent 542b9d30f0b151a85bad061f5c58c89b7d8827b0
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Thu, 19 Dec 2024 08:38:07 +0100
cleanup guidance
Diffstat:
| M | developers/style.rst | | | 86 | +++++++++++++++++++++++++++++++++++++++++-------------------------------------- |
1 file changed, 45 insertions(+), 41 deletions(-)
diff --git a/developers/style.rst b/developers/style.rst
@@ -392,8 +392,49 @@ Note that all commits **MUST** be signed with your GPG key.
The server will verify that any pushed commit is signed. It does not matter
which key is used (we do not keep a list of GPG public keys).
-We do not maintain a separate ChangeLog file anymore as the changes are
-documented in the git repositories.
+For any changes that are not minor, you should create an issue at
+https://bugs.gnunet.org and work in a branch that you may
+push to the project's server.
+For this, you can create a *developer branch*.
+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
+
+You will be able to force push to and delete branches under
+your prefix. It is highly recommended to work in your own developer
+branches.
+Most developers only have access to developer branches anyway.
+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\...
+
+- (optional) \...squash your commits,
+
+- rebase to master and then
+
+- ask that your branch is merged into master.
+
+- (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 ask your branch to be
+merged, you can then squash the commits or rename them.
+You can ask the project maintainer to merge your branch through any channel,
+but the gnunet-developers@gnu.org mailing list is the preferred method.
+
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
@@ -406,6 +447,8 @@ may also be included. Example:
# <subsystem>: <description>. (#XXXX)
IDENTITY: Fix wrong key construction for anonymous ECDSA identity. (Fixes #12344)
+We do not maintain a separate ChangeLog file anymore as the changes are
+documented in the git repositories.
If you edit files that change user-facing behaviour (e.g. header files in src/include)
you will have to add at least one line in the commit message starting with \"NEWS:\".
If there is a special reason why you deem this unnecessary, you can add the line
@@ -432,45 +475,6 @@ 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.
-Most developers only have access to developer branches anyway.
-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\...
-
-- (optional) \...squash your commits,
-
-- rebase to master and then
-
-- ask that your branch is merged into master.
-
-- (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 ask your branch to be
-merged, you can then squash the commits or rename them.
-You can ask the project maintainer to merge your branch through any channel,
-but the gnunet-developers@gnu.org mailing list is the preferred method.
-
