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.
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
