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

[Dylan Baker]

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.
Fixes apparently means "best effort only", Cc means "this must be applied", and
Ccing a patch after the fact isn't picked up by the scripts and instad requires
the stable maintainer to manually browse a mailing list, which has a very high
noise bias in signal to noise ratio.

Can we just use gitlab pull requests for stable branches? No fixes tags, no cc
stable. If someone wants a patch *any* patch in stable just make a PR.  gitlab
will tell that person the patch doesn't apply cleanly immediately, and a
pipeline can be used to tell them if the patch compiles.

I spend at least an hour a day pulling patches, reading mesa-stable, trying to
resolve merge conflicts, compile testing, and pushing things through our CI.

Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180921/b1fbecc3/attachment.sig>