xref: /aosp_15_r20/external/trace-cmd/CONTRIBUTE (revision 58e6ee5f017f6a8912852c892d18457e4bafb554)
1If you like to become part of the community and submit patches, here's how
2to do so for trace-cmd.
3
4If you only want to report a bug, or suggest an enhancement, you may do
5so at:
6
7  https://bugzilla.kernel.org/buglist.cgi?component=Trace-cmd%2FKernelshark
8
9All development is done via a mailing list:
10
11   http://vger.kernel.org/vger-lists.html#linux-trace-devel
12
13Patches should be sent to [email protected]
14
15Start by cloning the official repository:
16
17  git clone git://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git
18
19Make your changes. When you are satisfied with them, commit them into git.
20Here's some helpful hints for your git commits.
21
221) When making changes, please follow the coding style defined by the file
23   called CODING_STYLE in this directory.
24
252) Every commit should only do one thing.
26   That is, if your work requires some cleaning up of code, do that
27   clean up as a separate commit and not with your functional changes.
28   Find ways to take "steps" in modifying code. If you can break up
29   your changes in a series of steps, do so.
30
313) The commit log should start with a title. Like the below
32
33      trace-cmd: Add CONTRIBUTE file
34
35   Even though this repo is for trace-cmd, start the topic with
36   "trace-cmd:" because the commits will end up as patches to a mailing
37   list that handles other tracing repos, differentiating them with the subject
38   is useful. You can be more specific as well. If the change only affects the
39   "record" command, you may start the title with "trace-cmd record:".
40
414) The body of the commit (with a blank line from the title), should be self
42   contained, and explain why you are making the change. The title should hold
43   the "what" is changing, but the body contains the rationale for the change.
44   It should be a stand alone, and not state things like "See the next patch",
45   because when it is in git history, there's no knowing what the next patch
46   is.  You can make statements like "This is needed for a <future-feature>
47   that will come later". Where "<future-feature>" is something that you are
48   working on and the current commit is one of the steps required to get there.
49
505) Add your Developer Certificate of Origin (DCO) at the bottom of the commit
51   log. That is "Signed-off-by: Full Name <email>" where your full name is your
52   real name (no pseudonyms). Optionally, if you are making the change on
53   behalf of your company, you may also add your company name, if you are not
54   using your company's email. "Signed-off-by: Full Name (Company) <email>".
55   Please note, the DCO is your statement that you have the legal right to
56   make these changes for the project you are submitting to.
57
58You can use the Linux kernel "checkpatch.pl" script to help verify the formatting
59of your patch:
60
61  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl
62
63Please note that checkpatch.pl is a guide and not a hard rule. If it reports a
64fix that makes the code harder to read, that fix can probably be ignored.
65
66  git format-patch --stdout HEAD~1..HEAD | ./checkpatch.pl
67
68Finally, you can use the git "send-email" functionality:
69
70  git send-email --from='<your-email> --to='[email protected]' HEAD~1..HEAD
71
72If you are sending one patch, if you are adding more than one patch, also include
73a cover letter:
74
75  git send-email --cover-letter --annotate --from='<your-email> --to='[email protected]' <first-commit>~1..HEAD
76
77If you receive feedback on your patches, and plan on sending another version,
78please use the '-v' option to mark your patches that they are a new version.
79For example, if you add "-v2" to the above commands, instead of having:
80"[PATCH]" in the subject, it will have "[PATCH v2]", letting the reviewers know
81that this is a new version. If you send another version, use "-v3" and so on.
82
83For more information about git send-email:
84
85  https://git-scm.com/docs/git-send-email
86
87To keep track of the status of patches that have been submitted, check out:
88
89  https://patchwork.kernel.org/project/linux-trace-devel/list/
90
91If you would like to apply patches from the mailing list, you can use
92the "b4" utility.
93
94 $ pip install b4
95
96Then from the mailing list archive, find a message id from a patch or patch
97series. For example, to get the patch from:
98
99  https://lore.kernel.org/linux-trace-devel/[email protected]/
100
101 $ b4 am -o - [email protected] > /tmp/p.mbox
102 $ git am /tmp/p.mbox
103
104