[Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Mark Janes]

Emil Velikov <emil.l.velikov at gmail.com> writes:

> (Dropping Leo, since it doesn't affect him. He's already subscribed to
> the list.)
>
> On 6 April 2018 at 19:20, Mark Janes <mark.a.janes at intel.com> wrote:
>
>> I agree with you, however our release process still has a gap.  We
>> (Intel) test commits on master, and file bugs when we find them in i965
>> or other components.
>>
>> If those commits already have a stable tag in the commit message, they
>> will be shipped at a later date directly to customers, with no testing.
>> There is no way to blacklist broken patches in our Mesa's release
>> automation.
>>
> That's why I mentioned that the process cannot be fully automated ;-)
>
> Let me try to explain slightly differently. Amongst others you want:
>
> a) 24h (ish) buffer (getting closer to 0, as we reach the pre-release
> announcement) before landing fix in the stable branch.
>
> We had broken _badly_ a few multiple times, a balance between the two
> is essential.
>
> Looking at it from Jenkins POV:
> You don't want to test/bisect that master is broken, only to apply
> same patch and run Jenkins on the same broken patch.
>
>  - when issues to happen for example: fdo#103626 currently there's two
> ways to handle it
>
> 1) add the commit to bin/.cherry-ignore. latter of which means that
> you miss the patch when it's actually fixed up.
> See a094314340387ef2463ed8b4ddc9317bc539832b for context.

You are right.  We can just add the commit to .cherry-ignore files in
affected branches when the bug bisects to something with a stable tag.

> 2) carefully/manually git cherry-pick
> Doing this allowed me to add the regression to the tracker, as
> otherwise we would have missed it for 18.0.0 ;-)
>
> Yet we could introduce on-hold list to cherry-ignore. It's fairly trivial.
>
>
> Hope that makes things a bit clearer.
>
> -Emil