From 751c3e907432b9848f1b625a5e54fa2dcfab3b2d Mon Sep 17 00:00:00 2001 From: Daniel Borkmann Date: Fri, 15 Mar 2013 14:22:48 +0100 Subject: docs: add initial workflow document Trying to document the workflow that comes along with using this Git repository. Further ideas, additions to this document are welcome to create a unified frame for all maintainers, developers and (advanced) users. Signed-off-by: Daniel Borkmann --- Documentation/Workflow | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Documentation/Workflow (limited to 'Documentation') diff --git a/Documentation/Workflow b/Documentation/Workflow new file mode 100644 index 0000000..9ff3c45 --- /dev/null +++ b/Documentation/Workflow @@ -0,0 +1,64 @@ +Repository Workflow: +//////////////////// + +Here are some guidelines for users or developers regarding the work with this +Git repository. + +* Users: + +- steps to verify a release tag can be done with GPG: + git show maint-dborkman-pgp-pub | gpg --import + git show maint-tklauser-pgp-pub | gpg --import + git tag -v + +* Developers: + +- steps to submit a patch: + we follow in general a similar submission process as in the Linux kernel + read https://www.kernel.org/doc/Documentation/SubmittingPatches + read Documentation/SubmittingPatches + if a commit was acknowledged by someone, add + Acked-by: Random J Developer + if a bug was reported by someone, add + Reported-by: Random J Developer + if a feature was suggested by someone, add + Suggested-by: Random J Developer + if a commit was tested by someone, add + Tested-by: Random J Developer + if a commit was reviewed by someone, add + Reviewed-by: Random J Developer + if a bug was bisected by someone, add + Bisected-by: Random J Developer + in case tagging as mentioned above already happened internally + in your company by different persons, you can add those tags + before submission into the patch commit message + in case someone on the mailing list adds his/her *-by tag, it's the + job of the maintainer to keep track of that and to apply this properly + +* Maintainer: + +- steps to add your public GPG key: + gpg --gen-key [...] + gpg --list-keys [take the pubkey id you want to add] + gpg -a --export | git hash-object -w --stdin + + git tag -a maint--pgp-pub + .> + git push --tags + +- steps to make a new release: + set proper versioning in the Makefile itself + make release + git push --tags + upload tarballs to public dir + update website + email generated .MAIL_MSG to the mailing list, include + bcc to the maintainers listed in Documentation/Downstream + +- apply patches from non-maintainers, basic rules to follow: + preferred are patches that have been sent via git send-email + never do an automatic Github merge in case the pull request came from there + in case of Github we need to do cherry-picking + if it's a pull request, make sure it does not contain merges itself + always add your Signed-off-by to the commit message in case of an apply + patches must be rejected in case the developer's Signed-off-by is missing -- cgit v1.2.3-54-g00ecf