docs: add initial workflow document
authorDaniel Borkmann <dborkman@redhat.com>
Fri, 15 Mar 2013 13:22:48 +0000 (15 14:22 +0100)
committerDaniel Borkmann <dborkman@redhat.com>
Fri, 15 Mar 2013 13:22:48 +0000 (15 14:22 +0100)
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 <dborkman@redhat.com>
Documentation/Workflow [new file with mode: 0644]

diff --git a/Documentation/Workflow b/Documentation/Workflow
new file mode 100644 (file)
index 0000000..9ff3c45
--- /dev/null
@@ -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 <tag-name>
+
+* 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 <random@developer.example.org>
+       if a bug was reported by someone, add
+               Reported-by: Random J Developer <random@developer.example.org>
+       if a feature was suggested by someone, add
+               Suggested-by: Random J Developer <random@developer.example.org>
+       if a commit was tested by someone, add
+               Tested-by: Random J Developer <random@developer.example.org>
+       if a commit was reviewed by someone, add
+               Reviewed-by: Random J Developer <random@developer.example.org>
+       if a bug was bisected by someone, add
+               Bisected-by: Random J Developer <random@developer.example.org>
+       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 <pubid> | git hash-object -w --stdin
+       <git-object-id>
+       git tag -a maint-<short-name>-pgp-pub <git-object-id>
+       <log: Public key of <full name>.>
+       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