Documentation/Workflow

   1 Repository Workflow:
   2 ////////////////////
   3
   4 Here are some guidelines for users or developers regarding the work with this
   5 Git repository.
   6
   7 * Users:
   8
   9 - steps to verify a release tag can be done with GPG:
  10         git show maint-dborkman-pgp-pub | gpg --import
  11         git show maint-tklauser-pgp-pub | gpg --import
  12         git tag -v <tag-name>
  13
  14 * Developers:
  15
  16 - steps to submit a patch:
  17         we follow in general a similar submission process as in the Linux kernel
  18         read https://www.kernel.org/doc/Documentation/SubmittingPatches
  19         read Documentation/SubmittingPatches
  20         if a commit was acknowledged by someone, add
  21                 Acked-by: Random J Developer <random@developer.example.org>
  22         if a bug was reported by someone, add
  23                 Reported-by: Random J Developer <random@developer.example.org>
  24         if a feature was suggested by someone, add
  25                 Suggested-by: Random J Developer <random@developer.example.org>
  26         if a commit was tested by someone, add
  27                 Tested-by: Random J Developer <random@developer.example.org>
  28         if a commit was reviewed by someone, add
  29                 Reviewed-by: Random J Developer <random@developer.example.org>
  30         if a bug was bisected by someone, add
  31                 Bisected-by: Random J Developer <random@developer.example.org>
  32         in case tagging as mentioned above already happened internally
  33          in your company by different persons, you can add those tags
  34          before submission into the patch commit message
  35         in case someone on the mailing list adds his/her *-by tag, it's the
  36          job of the maintainer to keep track of that and to apply this properly
  37
  38 * Maintainer:
  39
  40 - steps to add your public GPG key:
  41         gpg --gen-key [...]
  42         gpg --list-keys [take the pubkey id you want to add]
  43         gpg -a --export <pubid> | git hash-object -w --stdin
  44         <git-object-id>
  45         git tag -a maint-<short-name>-pgp-pub <git-object-id>
  46         <log: Public key of <full name>.>
  47         git push --tags
  48
  49 - steps to make a new release:
  50         set proper versioning in the Makefile itself
  51         make release
  52         git push --tags
  53         upload tarballs to public dir
  54         update website
  55         email generated .MAIL_MSG to the mailing list, include
  56          bcc to the maintainers listed in Documentation/Downstream
  57
  58 - apply patches from non-maintainers, basic rules to follow:
  59         preferred are patches that have been sent via git send-email
  60         never do an automatic Github merge in case the pull request came from there
  61         in case of Github we need to do cherry-picking
  62         if it's a pull request, make sure it does not contain merges itself
  63         always add your Signed-off-by to the commit message in case of an apply
  64         patches must be rejected in case the developer's Signed-off-by is missing