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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
