[Mesa-dev] Stable release process

[Emil Velikov]

On 15 November 2016 at 16:57, Marek Olšák <maraeo at gmail.com> wrote:
> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 15 November 2016 at 16:13, Marek Olšák <maraeo at gmail.com> wrote:
>>> I think that if people add the Cc stable tag to patches that are going
>>> to land in master first, they shouldn't send it to the stable ML,
>>> because that is redundant. Yet, many people do that. I would go even
>>> further and say that any unreviewed patches shouldn't be sent to the
>>> stable ML. At least that would be my policy I were the release
>>> manager.
>>>
>> Since I'm no longer tracking nominated-but-not-merged-in-master
>> patches things are noticeably better.
>
> What about patches in mesa-stable that can't be merged to master,
> because master needs to be fixed differently? Will you then apply the
> patches from mesa-stable or ignore them?
>
> Based on experience, it looks like you ignore them completely, which
> is why many fixes that I sent for inclusion to stable branches only
> (not master) have never been applied. This process needs to be fixed.
>
Trivial patches are addressed, others are pinged. Trivial dependencies
are picked, non-trivial ones invalidate the nominated patch.
Backports are always appreciated - there's been a few from yourself,
Ilia and others.

One example/snippet from the 12.0.x pre-release announcement.
"
      f240ad9 st/mesa: unduplicate st_check_sync code
      b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync

Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
fence_finish") which is gallium API change.
"
Here the original nominations are invalidated, and from a quick look
even if we do pick the dependency things won't work [as expected]
since zero drivers hadnle the pipe_ctx this will need to add support
(read: not bugfix, but implement).

In all fairness if sounds like things are unclear rather than anything
else. I believe with the documentation (and above) things are better
now ?
Flashback - sounds similar to the libdrm <> kernel chat we had a while
back ? Where you wanted to "fix" the kernel, rather than resync
libdrm.

Thanks
Emil