Lines Matching +full:- +full:- +full:no +full:- +full:commit +full:- +full:id
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dt…
4 <meta http-equiv="content-type" content="text/html; charset=utf-8">
26 <li><a href="#nominations">Nominating a commit for a stable branch</a>
31 <h2 id="guidelines">Basic guidelines</h2>
44 <li>Patches should be submitted to <a href="#mailing">mesa-dev</a>
45 for <a href="#reviewing">review</a> using <code>git send-email</code>.
49 <h2 id="formatting">Patch formatting</h2>
53 displayed in 80-column terminals avoid line wrapping. Note that git
67 i965: Remove end-of-thread SEND alignment code.
70 for Sandybridge (commit 077d01b6). There is no documentation saying this
71 is necessary, and removing it causes no regressions in piglit on any
74 <li>A "Signed-off-by:" line is not required, but not discouraged either.
78 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
86 there is no requirement to support native S8 for this,
99 Tested-by: Joe Hacker <jhacker@foo.com>
104 Reviewed-by: Joe Hacker <jhacker@foo.com>
105 Acked-by: Joe Hacker <jhacker@foo.com>
107 <li>If sending later revision of a patch, add all the tags - ack, r-b,
108 Cc: mesa-stable and/or other. This provides reviewers with quick feedback if the
117 $ scripts/get_reviewer.pl --help # to get the the help screen
118 $ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
127 <h2 id="testing">Testing Patches</h2>
149 <h2 id="mailing">Mailing Patches</h2>
152 Patches should be sent to the mesa-dev mailing list for review:
153 <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">
154 mesa-dev@lists.freedesktop.org</a>.
156 <a href="https://git-scm.com/docs/git-send-email">git send-email</a>
158 attachments prevents people from being able to provide in-line review
163 When submitting follow-up patches you can use --in-reply-to to make v2, v3,
166 re-sending the whole series). Using --in-reply-to makes
171 When submitting follow-up patches you should also login to
176 <h2 id="reviewing">Reviewing Patches</h2>
183 Reviewed-by: Joe Hacker <jhacker@foo.com>
187 Acked-by: Joe Hacker <jhacker@foo.com>
197 With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
205 <h2 id="nominations">Nominating a commit for a stable branch</h2>
212 <li> By adding the Cc: mesa-stable@ tag as described below.
213 <li> Sending the commit ID (as seen in master branch) to the mesa-stable@ mailing list.
214 <li> Forwarding the patch from the mesa-dev@ mailing list.
218 Note: resending patch identical to one on mesa-dev@ or one that differs only
219 by the extra mesa-stable@ tag is <strong>not</strong> recommended.
223 <h3 id="thetag">The stable tag</h3>
226 If you want a commit to be applied to a stable branch,
227 you should add an appropriate note to the commit message.
234 <li>CC: <mesa-stable@lists.freedesktop.org></li>
235 <li>CC: "9.2 10.0" <mesa-stable@lists.freedesktop.org></li>
236 <li>CC: "10.0" <mesa-stable@lists.freedesktop.org></li>
239 Simply adding the CC to the mesa-stable list address is adequate to nominate
240 the commit for the most-recently-created stable branch. It is only necessary
242 examples above), if you want to nominate the commit for an older stable
243 branch. And, as in these examples, you can nominate the commit for the older
244 branch in addition to the more recent branch, or nominate the commit
248 copied to the mesa-stable@ mailing list when you use "git send-email" to send
249 patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that
253 Note: by removing the tag [as the commit is pushed] the patch is
259 <h2 id="criteria">Criteria for accepting patches to the stable branch</h2>
266 The stable-release manager will work with the list of nominated patches, and
267 for each patch that meets the criteria below will cherry-pick the patch with:
268 <code>git cherry-pick -x <commit></code>. The <code>-x</code> option is
269 important so that the picked patch references the commit ID of the original
272 The stable-release manager may at times need to force-push changes to the
273 stable branches, for example, to drop a previously-picked patch that was later
274 identified as causing a regression). These force-pushes may cause changes to
278 The stable-release manager is also given broad discretion in rejecting patches
280 the stable branch is for bug fixes only, (no new features, no
281 regressions). Here is a non-exhaustive list of some reasons that a patch may
286 regression caused by a particular patch, (game no longer work, piglit test
291 <li>Patch is not a fix. For example, a commit that moves code around with no
294 <li>Patch fix is not clearly described. For example, a commit message
295 of only a single line, no description of the bug, no mention of bugzilla,
298 <li>Patch has not obviously been reviewed, For example, the commit message
299 has no Reviewed-by, Signed-off-by, nor Tested-by tags from anyone but the
304 first on the master branch and then be cherry-picked to a stable
310 <li>Patch depends on too many other patches. Ideally, all stable-branch
311 patches should be self-contained. It sometimes occurs that a single, logical
312 bug-fix occurs as two separate patches on master, (such as an original
313 patch, then a subsequent fix-up to that patch). In such a case, these two
314 patches should be squashed into a single, self-contained patch for the
322 Note: As an exception to this rule, the stable-release manager may accept
323 hardware-enabling "features". For example, backports of new code to support
324 a newly-developed hardware product can be accepted if they can be reasonably
332 non-controversial and the patches still need to meet the other criteria of
333 being simple and self-contained</li>
339 previously working, (even if technically non-compliant with the
344 <h2 id="gittips">Git tips</h2>
347 <li><code>git rebase -i ...</code> is your friend. Don't be afraid to use it.
348 <li>Apply a fixup to commit FOO.
351 git commit --fixup=FOO
352 git rebase -i --autosquash ...
356 git rebase -i --exec="make -j4" HEAD~8
360 git config --local sendemail.to mesa-dev@lists.freedesktop.org
365 git send-email --subject-prefix="PATCH v4" HEAD~8
366 git send-email -v4 @~8 # shorter version, inherited from git format-patch
371 git config sendemail.cccmd "./scripts/get_reviewer.pl -i"