Quoting Emil Velikov (2018-09-21 09:07:58) > On 21 September 2018 at 16:55, Dylan Baker <dy...@pnwbakers.com> wrote: > > Quoting Emil Velikov (2018-09-21 08:47:30) > >> On 21 September 2018 at 08:19, Juan A. Suarez Romero > >> <jasua...@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.engest...@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.engest...@intel.com> > >> >> > > >> >> > > CC: <mesa-sta...@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
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
