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>
32 <h2 id="guidelines">Basic guidelines</h2>
45 <li>Patches should be submitted to <a href="#mailing">mesa-dev</a>
46 for <a href="#reviewing">review</a> using <code>git send-email</code>.
50 <h2 id="formatting">Patch formatting</h2>
54 displayed in 80-column terminals avoid line wrapping. Note that git
68 i965: Remove end-of-thread SEND alignment code.
71 for Sandybridge (commit 077d01b6). There is no documentation saying this
72 is necessary, and removing it causes no regressions in piglit on any
75 <li>A "Signed-off-by:" line is not required, but not discouraged either.
79 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
81 <li>If a patch addresses a issue introduced with earlier commit, that should be
92 there is no requirement to support native S8 for this,
105 Tested-by: Joe Hacker <jhacker@foo.com>
110 Reviewed-by: Joe Hacker <jhacker@foo.com>
111 Acked-by: Joe Hacker <jhacker@foo.com>
113 <li>If sending later revision of a patch, add all the tags - ack, r-b,
114 Cc: mesa-stable and/or other. This provides reviewers with quick feedback if the
123 $ scripts/get_reviewer.pl --help # to get the help screen
124 $ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
133 <h2 id="testing">Testing Patches</h2>
157 to run your tests on each commit. Assuming your branch is based off
160 $ git rebase --interactive --exec "make check" origin/master
167 <h2 id="mailing">Mailing Patches</h2>
170 Patches should be sent to the mesa-dev mailing list for review:
171 <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">
172 mesa-dev@lists.freedesktop.org</a>.
174 <a href="https://git-scm.com/docs/git-send-email">git send-email</a>
176 attachments prevents people from being able to provide in-line review
181 When submitting follow-up patches you can use --in-reply-to to make v2, v3,
184 re-sending the whole series). Using --in-reply-to makes
189 When submitting follow-up patches you should also login to
204 <h2 id="reviewing">Reviewing Patches</h2>
211 Reviewed-by: Joe Hacker <jhacker@foo.com>
215 Acked-by: Joe Hacker <jhacker@foo.com>
225 With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
233 <h2 id="nominations">Nominating a commit for a stable branch</h2>
240 <li> By adding the Cc: mesa-stable@ tag as described below.
241 <li> Sending the commit ID (as seen in master branch) to the mesa-stable@ mailing list.
242 <li> Forwarding the patch from the mesa-dev@ mailing list.
246 Note: resending patch identical to one on mesa-dev@ or one that differs only
247 by the extra mesa-stable@ tag is <strong>not</strong> recommended.
251 <h3 id="thetag">The stable tag</h3>
254 If you want a commit to be applied to a stable branch,
255 you should add an appropriate note to the commit message.
262 <li>CC: <mesa-stable@lists.freedesktop.org></li>
265 Simply adding the CC to the mesa-stable list address is adequate to nominate
266 the commit for all the active stable branches. If the commit is not applicable
267 for said branch the stable-release manager will reply stating so.
270 copied to the mesa-stable@ mailing list when you use "git send-email" to send
271 patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that
275 Note: by removing the tag [as the commit is pushed] the patch is
282 section, it nominates a commit for all active stable branches that include the
283 commit that is referred to.
285 <h2 id="criteria">Criteria for accepting patches to the stable branch</h2>
292 stable-release manager is also given broad discretion in rejecting patches
302 <li>It must not introduce a regression - be that build or runtime wise.
310 <li>Patches that move code around with no functional change should be
315 Note: An exception to this rule, are hardware-enabling "features". For
317 newly-developed hardware product can be accepted if they can be reasonably
320 <li>Patch must be reviewed, For example, the commit message has Reviewed-by,
321 Signed-off-by, or Tested-by tags from someone but the author.</li>
329 <a href="releasing.html#pickntest">cherry-picked</a>. Alternatively the release
334 <a href="releasing.html#prerelease">pre-release</a> announcement.
336 The stable-release manager may at times need to force-push changes to the
337 stable branches, for example, to drop a previously-picked patch that was later
338 identified as causing a regression). These force-pushes may cause changes to
342 <h2 id="backports">Sending backports for the stable branch</h2>
343 By default merge conflicts are resolved by the stable-release manager. In which
346 <a href="releasing.html#prerelease">pre-release</a> announcement.
350 within the commit summary.
352 <h2 id="gittips">Git tips</h2>
355 <li><code>git rebase -i ...</code> is your friend. Don't be afraid to use it.
356 <li>Apply a fixup to commit FOO.
359 git commit --fixup=FOO
360 git rebase -i --autosquash ...
364 git rebase -i --exec="make -j4" HEAD~8
368 git config --local sendemail.to mesa-dev@lists.freedesktop.org
373 git send-email --subject-prefix="PATCH v4" HEAD~8
374 git send-email -v4 @~8 # shorter version, inherited from git format-patch
379 git config sendemail.cccmd "./scripts/get_reviewer.pl -i"