[Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.

[Emil Velikov]

On 23 September 2018 at 14:53, Bas Nieuwenhuizen
<bas at basnieuwenhuizen.nl> wrote:
> On Sun, Sep 23, 2018 at 3:42 PM Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>
>> On 21 September 2018 at 17:49, Dylan Baker <dylan at pnwbakers.com> wrote:
>> > Quoting Emil Velikov (2018-09-21 09:07:58)
>> >> On 21 September 2018 at 16:55, Dylan Baker <dylan at pnwbakers.com> wrote:
>> >> > Quoting Emil Velikov (2018-09-21 08:47:30)
>> >> >> On 21 September 2018 at 08:19, Juan A. Suarez Romero
>> >> >> <jasuarez at igalia.com> wrote:
>> >> >> > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote:
>> >> >> >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom <eric.engestrom at intel.com> wrote:
>> >> >> >> >
>> >> >> >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote:
>> >> >> >> > > Was missing the init, found by Emil.
>> >> >> >> > >
>> >> >> >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID."
>> >> >> >> >
>> >> >> >> > Reviewed-by: Eric Engestrom <eric.engestrom at intel.com>
>> >> >> >> >
>> >> >> >> > > CC: <mesa-stable at lists.freedesktop.org>
>> >> >> >> >
>> >> >> >> > Cc'ing mesa-stable has no effect when you're already adding the
>> >> >> >> > proper Fixes: tag :)
>> >> >> >>
>> >> >> >> Last time I asked about the difference between Fixes and CC, the
>> >> >> >> conclusion I got that Fixes is only best effort for the stable
>> >> >> >> branches and that if it does not apply it will be dropped silently,
>> >> >> >> while for the CC ones the release manager will notify you.
>> >> >> >>
>> >> >> >
>> >> >> > In previous releases that was the way it worked: we always our best effort to
>> >> >> > apply CC and Fixes patches. The difference was that if we couldn't apply the
>> >> >> > patch, then we were only notifying in the pre-announcement "Rejected" section
>> >> >> > about the CC, and silently ignoring the Fixes.
>> >> >> >
>> >> >> >
>> >> >> > But nowadays, we notify about all the candidates to stable, which are CC and
>> >> >> > Fixes.
>> >> >> >
>> >> >> Here is an alternative wording, hopefully it will make things clearer:
>> >> >>
>> >> >> Both CC and Fixes work and having both does not hurt.
>> >> >>
>> >> >> Fixes provides clear indication when/where the problem originates.
>> >> >> Cc _explicitly_ requests the patch to be in stable - that's why we
>> >> >> have the list + late nominations.
>> >> >>
>> >> >> It _explicit_ nomination does _not_ apply then the nominator is informed.
>> >> >>
>> >> >> -Emil
>> >> >
>> >> > Yeah, that's not useful. We don't need a "you can put this in if you want but
>> >> > don't tell me if you didn't". Either it's nominated or it's not. If Fixes:
>> >> > doesn't mean "I want this in any stable branch with commit X" then we should
>> >> > stop using the tag.
>> >> >
>> >> Fixes means "I want this _anywhere_ with commit X". No idea how you
>> >> read my comment otherwise ;-)
>> >>
>> >> -Emil
>> >
>> > Where you said CC is _explicit_ but fixes isn't. Having two ways to do the same
>> > thing that are subtly different seems like a bad idea to me.
>> >
>> > I'm going to admit this is just another reason that I feel like our whole stable
>> > process is rather fragile and tedious. We have three ways to nominate a patch
>> > that are all subtly different, but those differences are not clearly documented.
>>
>> Keep in mind that before I started the documentation was a mere
>> fraction of what it is today.
>> As I said multiple times if something is unclear - ask _and_ send
>> patches to clarify the documentation.
>>
>> Sadly close to no patches appear :-(
>
> I'm happy to send patches to clarify the documentation once this
> discussion is through. However, I'm not sure how to reconcile your
> statements though:
>
> "Both CC and Fixes work and having both does not hurt.
>
> Fixes provides clear indication when/where the problem originates.
> Cc _explicitly_ requests the patch to be in stable - that's why we
> have the list + late nominations.
>
> It _explicit_ nomination does _not_ apply then the nominator is informed."
>
> which seems to say that patches with only "Fixes:" can get rejected
> silently. (which would match Juan's old answer in
> https://lists.freedesktop.org/archives/mesa-stable/2018-April/008072.html)
>
I _really_ should have read that clearer. I have no recollection of a
Fixes patch which was rejected, might may have brought some confusion
on my end.

> vs.
>
> "As a TL;DR _nothing_ is rejected silently ;-)"
>
> which seems to say that patches with only "Fixes:" can not get
> rejected silently. (which matches what Dylan is saying)
>
> While documentation can help prevent future confusion/discussion on
> this topic, which way should the documentation go, as these two
> statements seem to contradict each other to me.
>
Agreed. I will be mentioning a thing or two about the history what
things mean (from my POV that is) and why in a couple of days at XDC.
After that I'm planning to gather feedback from everyone so we can
adjust things accordingly.

-Emil