gnunet-handbook

commit ad5e61cf884c16c33711611ee96433245a37020a
parent 86ff602297a9793f38445923ddf789ab7f56a658
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Tue, 17 Dec 2024 14:50:38 +0100

update dev access info

Diffstat:
M
developers/style.rst
 | 
37
++++++++++++++++++++++++++++---------

1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/developers/style.rst b/developers/style.rst
@@ -373,10 +373,21 @@ 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
-======================================
+
+Minor contributions
+===================
+
+Smaller contributions should be provided as patches and not in
+developer branches that require git access (see below).
+You may post patches on https://bugs.gnunet.org in a new or existing
+(relevant) issue or on the mailing list gnunet-developers@gnu.org.
+
+Developer access and commit messages
+====================================
 
 You can find the GNUnet project repositories at https://git.gnunet.org.
+The following applies to all repositories, but access policies are only
+enforced for the main gnunet repository.
 We do not maintain a separate ChangeLog file anymore as the changes are
 documented in the git repositories.
 Commit messages are required to convey what changes were
@@ -435,27 +446,35 @@ branch for an i18n fix, the branch name could be:
 
 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
+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\...
 
--  \...squash your commits,
+-  (optional) \...squash your commits,
 
 -  rebase to master and then
 
--  merge your branch.
+-  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 merge your branch,
-you can then squash the commits or rename them.
+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.
+
+
 
 
 Releases
 ========
 
+Packaging a release can only be done by a maintainer.
+
 In this order do:
 
 0. Update your local tree
@@ -470,7 +489,7 @@ In this order do:
 
 5. Tag the release (Named commit!)
 
-6. Run ``./bootstrap`` again and create tarball
+6. Run ``./autoreconf -if`` and create tarball
 
 7. **IMPORTANT**: Compile and test tarballs
   
@@ -525,7 +544,7 @@ Then, update the po files:
 
    $ cd po && make update-po && cd ..
 
-Commit all changes in the source tree now.
+Commit all changes in the source tree now, and push the changes.
 
 **(5)** You can now tag the release. Please **always** use named tags (important for our
 nightly tarball build trigger).