Emil Velikov <emil.l.veli...@gmail.com> writes: > On 4 April 2018 at 17:40, Mark Janes <mark.a.ja...@intel.com> wrote: >> Leo Liu <leo....@amd.com> writes: >> >>> On the CI family, firmware requires the destory command have to be the >>> last command in the IB, moving feedback command after destroy is causing >>> issues on CI cards, so we have to keep the previous logic that moves >>> destroy back to the last command. >>> >>> But as the original issue fixed previously, with the newer family like >>> Vega10, >>> feedback command have to be included inside of the task info command along >>> with destroy command. >>> >>> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command") >>> >>> Signed-off-by: Leo Liu <leo....@amd.com> >>> Cc: mesa-sta...@lists.freedesktop.org >> >> These tags seem ambiguous to me. If this commit fixes a specific >> commit, then the patch should be applied only to stable branches which >> contain that commit. >> >> However, the mesa-stable CC caused this patch to be applied to 17.3, >> which does *not* contain the broken patch. >> >> Leo: did you intend for the mesa-stable CC to cause this patch to be >> applied to older stable branches? >> >> Release managers: is there a protocol for how this specification should >> be parsed, when considering a patch for stable? >> > If the Fixes tag, reference a commit that is missing in specific > stable branch then obviously the fix is not suitable. > Hence the stable piece than be ignored + alongside a reply to the > patch that it will not be in $stable_branch because $reason.
OK, we have violated this policy at least a couple times in the previous release, based on my audits: 2f67c9b17518cf0d2fe946e39e5b8ff5ec2797c5 i965/vec4: Fix null destination register in 3-source instructions 6f69b63896ce2352aaa25f89287133f7f2ba1fab radeon/vce: move feedback command inside of destroy function > Even if offending commit is not part of $stable_branch, getting into > the habit and cross-referencing is very beneficial. > Some customers may use non-stable branch, hence having track of which > fixes they need is a smart move. > > HTH > Emil _______________________________________________ mesa-dev mailing list email@example.com https://lists.freedesktop.org/mailman/listinfo/mesa-dev