From d2d2b5d96121ba427f6b23b64aa38a77d6bf7ace Mon Sep 17 00:00:00 2001 From: Daniel Borkmann Date: Thu, 11 Apr 2013 16:52:24 +0200 Subject: docs: move some of them to the root directory Lets move CodingStyle, SubmittingPatches, and Sponsors into the root directory of netsniff-ng and remove the Documentation folder. Some of those files are quite bloated, and most of these things should be in the man-pages anyway. They should be the only big sources of documentation, nothing else. The rest is currently put here: http://pub.netsniff-ng.org/docs/ Signed-off-by: Daniel Borkmann --- Documentation/Workflow | 64 -------------------------------------------------- 1 file changed, 64 deletions(-) delete mode 100644 Documentation/Workflow (limited to 'Documentation/Workflow') diff --git a/Documentation/Workflow b/Documentation/Workflow deleted file mode 100644 index 9ff3c45..0000000 --- a/Documentation/Workflow +++ /dev/null @@ -1,64 +0,0 @@ -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