1 File.........: 7 - Contributing to crosstool-NG.txt
2 Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
3 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
6 Contributing to crosstool-NG /
7 _____________________________/
10 Sending a bug report |
11 ---------------------+
13 If you need to send a bug report, please send a mail with subject
14 prefixed with "[CT_NG]" with to following destinations:
15 TO: yann.morin.1998 (at) anciens.enib.fr
16 CC: crossgcc (at) sourceware.org
22 If you want to enhance crosstool-NG, there's a to-do list in the TODO file.
24 Patches should come with the appropriate SoB line. A SoB line is typically
26 Signed-off-by: John DOE <john.doe@somewhere.net>
28 The SoB line is clearly described in Documentation/SubmittingPatches , section
29 12, of your favourite Linux kernel source tree.
32 How to Use Mercurial |
33 ---------------------+
35 For larger or more frequent contributions, mercurial should be used.
39 Configuring Mercurial:
40 You need mercurial with the following extensions:
41 - mq : http://mercurial.selenic.com/wiki/MqExtension
42 - patchbomb : http://mercurial.selenic.com/wiki/PatchbombExtension
43 Usually, these two extensions are already part of the installation package.
44 The mq extension maintains a separate queue of your local changes
45 that you can change at any later time.
46 With the patchbomb extension you can email those patches directly
49 Your configuration file for mercurial, e.g. ~/.hgrc should contain
50 at least the following sections (but have a look at `man hgrc`):
53 # configure sending patches directly via Mercurial
54 from = "Your Name" <your@email.address>
59 # SMTP configuration (only for method=smtp)
66 # The following lines enable the two extensions:
71 Create your local repository as a clone:
72 hg clone http://ymorin.is-a-geek.org/hg/crosstool-ng crosstool-ng
74 Setting up the mq extension in your local copy:
81 Recording your changes in the patch queue maintained by mq:
82 # First, create a new patch entry in the patch queue:
83 hg qnew -D -U -e short_patch_name1
84 <edit patch description as commit message (see below for an example)>
86 <now edit the ct-ng sources and check them>
88 # if you execute `hg status` here, your modifications of the working
89 # copy should show up.
91 # Now the following command takes your modifications from the working copy
92 # into the patch entry
94 <reedit patch description [-e] if desired>
96 # Now your changes are recorded, and `hg status` should show a clean
99 Repeat the above steps for all your modifications.
100 The command `hg qseries` informs you about the content of your patch queue.
103 CONTRIBUTING YOUR PATCHES:
105 Once you are satisfied with your patch series, you can (you should!)
106 contribute them back to upstream.
107 This is easily done using the `hg email` command.
109 `hg email` sends your new changesets to a specified list of recipients,
110 each patch in its own email, all ordered in the way you entered them (oldest
111 first). The command line flag --outgoing selects all changesets that are in
112 your local but not yet in the upstream repository. Here, these are exactly
113 the ones you entered into your local patch queue in the section above, so
114 --outgoing is what you want.
116 Each email gets the subject set to: "[PATCH x of n] <series summary>"
117 where 'x' is the serial number in the email series, and 'n' is the total number
118 of patches in the series. The body of the email is the complete patch, plus
119 a handful of metadata, that helps properly apply the patch, keeping the log
120 message, attribution and date, tracking file changes (move, delete, modes...)
122 `hg email` also threads all outgoing patch emails below an introductory
123 message. You should use the introductory message (command line flag --intro)
124 to describe the scope and motivation for the whole patch series. The subject
125 for the introductory message gets set to: "[PATCH 0 of n] <series summary>"
126 and you get the chance to set the <series summary>.
128 Here is a sample `hg email` complete command line:
129 Note: replace " (at) " with "@"
131 hg email --outgoing --intro \
132 --to '"Yann E. MORIN" <yann.morin.1998 (at) anciens.enib.fr>' \
133 --cc 'crossgcc (at) sourceware.org'
135 # It then opens an editor and lets you enter the subject
136 # and the body for the introductory message.
138 Use `hg email` with the additional command line switch -n to
139 first have a look at the email(s) without actually sending them.
142 MAINTAINING YOUR PATCHES:
144 When the patches are refined by discussing them on the mailing list,
145 you may want to finalize and resend them.
147 The mq extension has the idiosyncrasy of imposing a stack onto the queue:
148 You can always reedit/refresh only the patch on top of stack.
149 The queue consists of applied and unapplied patches
150 (if you reached here via the above steps, all of your patches are applied),
151 where the 'stack' consists of the applied patches, and 'top of stack'
152 is the latest applied patch.
154 The following output of `hg qseries` is now used as an example:
155 0 A short_patch_name1
156 1 A short_patch_name2
157 2 A short_patch_name3
158 3 A short_patch_name4
160 You are now able to edit patch 'short_patch_name4' (which is top of stack):
164 <and optionally [-e] reedit the commit message>
166 If you want to edit e.g. patch short_patch_name2, you have to modify
167 mq's stack so this patch gets top of stack.
168 For this purpose see `hg help qgoto`, `hg help qpop`, and `hg help qpush`.
170 hg qgoto short_patch_name2
171 # The patch queue should now look like
173 0 A short_patch_name1
174 1 A short_patch_name2
175 2 U short_patch_name3
176 3 U short_patch_name4
177 # so patch # 1 (short_patch_name2) is top of stack.
178 <now reedit the sources for short_patch_name2>
181 <and optionally [-e] reedit the commit message>
182 # the following command reapplies the now unapplied two patches:
184 # you can also use `hg qgoto short_patch_name4` to get there again.
187 RESENDING YOUR REEDITED PATCHES:
189 By mailing list policy, please resend your complete patch series.
190 --> Go back to section "CONTRIBUTING YOUR PATCHES" and resubmit the full set.
193 SYNCING WITH UPSTREAM AGAIN:
195 You can sync your repo with upstream at any time by executing
196 # first unapply all your patches:
198 # next fetch new changesets from upstream
200 # then update your working copy
202 # optionally remove already upstream integrated patches (see below)
203 hg qdelete <short_name_of_already_applied_patch>
204 # and reapply your patches if any non upstream-integrated left (but see below)
207 Eventually, your patches get included into the upstream repository
208 which you initially cloned.
209 In this case, before executing the hg qpush -a from above
210 you should manually "hg qdelete" the patches that are already integrated upstream.
213 HOW TO FORMAT COMMIT MESSAGES (aka patch desciptions):
215 Commit messages should look like (without leading pipes):
216 |component: short, one-line description
218 |optional longer description
219 |on multiple lines if needed
221 Here is an example commit message (see revision a53a5e1d61db):
222 |comp-libs/cloog: fix building
224 |For CLooG/PPL 0.15.3, the directory name was simply cloog-ppl.
225 |For any later versions, the directory name does have the version, such as