- mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG +mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG - gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY +gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY - i965: Fix missing type in local variable declaration. +i965: Fix missing type in local variable declaration.
- i965: Remove end-of-thread SEND alignment code. +i965: Remove end-of-thread SEND alignment code. - This was present in Eric's initial implementation of the compaction code - for Sandybridge (commit 077d01b6). There is no documentation saying this - is necessary, and removing it causes no regressions in piglit on any - platform. +This was present in Eric's initial implementation of the compaction code +for Sandybridge (commit 077d01b6). There is no documentation saying this +is necessary, and removing it causes no regressions in piglit on any +platform.
- Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1 +Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
Prefer the full url to just Closes: #1, since the url makes it
easier to get to the bug page from git log
git log
- Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory" +Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"@@ -93,29 +93,29 @@ once and then using
git fixes <sha1>
- st/mesa: add ARB_texture_stencil8 support (v4) - - if we support stencil texturing, enable texture_stencil8 - there is no requirement to support native S8 for this, - the texture can be converted to x24s8 fine. - - v2: fold fixes from Marek in: - a) put S8 last in the list - b) fix renderable to always test for d/s renderable - fixup the texture case to use a stencil only format - for picking the format for the texture view. - v3: hit fallback for getteximage - v4: put s8 back in front, it shouldn't get picked now (Ilia) +st/mesa: add ARB_texture_stencil8 support (v4) + +if we support stencil texturing, enable texture_stencil8 +there is no requirement to support native S8 for this, +the texture can be converted to x24s8 fine. + +v2: fold fixes from Marek in: + a) put S8 last in the list + b) fix renderable to always test for d/s renderable + fixup the texture case to use a stencil only format + for picking the format for the texture view. +v3: hit fallback for getteximage +v4: put s8 back in front, it shouldn't get picked now (Ilia)
- Tested-by: Joe Hacker <jhacker@foo.com> +Tested-by: Joe Hacker <jhacker@foo.com>
- Reviewed-by: Joe Hacker <jhacker@foo.com> - Acked-by: Joe Hacker <jhacker@foo.com> +Reviewed-by: Joe Hacker <jhacker@foo.com> +Acked-by: Joe Hacker <jhacker@foo.com>
-As mentioned at the begining, patches should be bisectable.
+As mentioned at the beginning, patches should be bisectable.
A good way to test this is to make use of the `git rebase` command,
to run your tests on each commit. Assuming your branch is based off
origin/master, you can run:
@@ -225,11 +225,11 @@ When you've reviewed a patch, please be unambiguous about your review.
That is, state either
- Reviewed-by: Joe Hacker <jhacker@foo.com> +Reviewed-by: Joe Hacker <jhacker@foo.com>or
- Acked-by: Joe Hacker <jhacker@foo.com> +Acked-by: Joe Hacker <jhacker@foo.com>
Rather than saying just "LGTM" or "Seems OK". @@ -239,7 +239,7 @@ Rather than saying just "LGTM" or "Seems OK". If small changes are suggested, it's OK to say something like:
- With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com> +With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
which tells the patch author that the patch can be committed, as long @@ -256,7 +256,7 @@ When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR, enclose the tag in backticks:
- `Reviewed-by: Joe Hacker <jhacker@example.com>`+`Reviewed-by: Joe Hacker <jhacker@example.com>`
This is the markdown format for literal, and will prevent gitlab from hiding the < and > symbols. @@ -278,13 +278,14 @@ release.
-Note: resending patch identical to one on mesa-dev@ or one that differs only -by the extra mesa-stable@ tag is not recommended. +Please DO NOT send patches to +mesa-stable@lists.freedesktop.org, it is not monitored actively and is a +historical artifact.
If you are not the author of the original patch, please Cc: them in your @@ -303,31 +304,27 @@ you should add an appropriate note to the commit message.
+Using a "fixes tag" as described in Patch formatting +is the preferred way to nominate a commit that you know ahead of time should be +backported. There are scripts that will figure out which releases to apply the +patch to automatically, so you don't need to figure it out. +
+ ++Alternatively, you may use a "CC:" tag. + Here are some examples of such a note:
-CC: <mesa-stable@lists.freedesktop.org> +CC: 20.0 19.3 <mesa-stable@lists.freedesktop.org>-Simply adding the CC to the mesa-stable list address is adequate to nominate -the commit for all the active stable branches. If the commit is not applicable -for said branch the stable-release manager will reply stating so. - -This "CC" syntax for patch nomination will cause patches to automatically be -copied to the mesa-stable@ mailing list when you use "git send-email" to send -patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that -won't have any negative effect on the patch nomination. -
-Note: by removing the tag [as the commit is pushed] the patch is -explicitly rejected from inclusion in the stable branch(es). -Thus, drop the line only if you want to cancel the nomination. +Using the CC tag should include the stable branches you want +to nominate the patch to. If you do not provide any version it is nominated to +all active stable branches.
-Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting" -section, it nominates a commit for all active stable branches that include the -commit that is referred to. -
-By default merge conflicts are resolved by the stable-release manager. In which
-case he/she should provide a comment about the changes required, alongside the
-Conflicts section. Summary of which will be provided in the
-pre-release announcement.
+By default merge conflicts are resolved by the stable-release manager. The
+release maintainer should resolve trivial conflicts, but for complex conflicts
+they should ask the original author to provide a backport or de-nominate the
+patch.
-Developers are interested in sending backports are recommended to use either a
-[BACKPORT #branch] subject prefix or provides similar information
-within the commit summary.
+For patches that either need to be nominated after they've landed in master, or
+that are known ahead of time to not not apply cleanly to a stable branch (such
+as due to a rename), using a gitlab MR is most appropriate.
+
+The MR should be based on and target the staging/year.quarter branch, not on
+the year.quarter branch, per the stable branch policy.
+
+Assigning the MR to release maintainer for said branch or mentioning them is
+helpful, but not required.
git rebase -i ... is your friend. Don't be afraid to use it.
- git add ... - git commit --fixup=FOO - git rebase -i --autosquash ... +git add ... +git commit --fixup=FOO +git rebase -i --autosquash ...
- git rebase -i --exec="ninja -C build/" HEAD~8 +git rebase -i --exec="ninja -C build/" HEAD~8
- git config --local sendemail.to mesa-dev@lists.freedesktop.org +git config --local sendemail.to mesa-dev@lists.freedesktop.org
- git send-email --subject-prefix="PATCH v4" HEAD~8 - git send-email -v4 @~8 # shorter version, inherited from git format-patch +git send-email --subject-prefix="PATCH v4" HEAD~8 +git send-email -v4 @~8 # shorter version, inherited from git format-patch