[Mesa-dev] Stable release process

Marek Olšák maraeo at gmail.com
Thu Nov 17 23:42:50 UTC 2016


On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 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 ?

That's all nice, but it's mostly irrelevant to what I was saying.

We need Patchwork for mesa-stable, so that patches don't get lost.

Marek


More information about the mesa-dev mailing list