[Mesa-dev] Stable release process

[Marek Olšák]

On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 17 November 2016 at 23:42, Marek Olšák <maraeo at gmail.com> wrote:
>> 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.
>>
> Ok let me be perfectly clear.
>
> Nearly all the missed patches (many of those sent by you) do _not_
> follow the -stable submission rules. I've been polite and picked those
> _despite_ that fact and yes some have been missed.
> Regardless of patchwork I would _strongly_ suggest that you stay
> consistent (you do it right most of the time) and nominate patches
> properly!

The last one was nominated properly, and ignored. It didn't mention
anything about the app it was fixing, but I couldn't tell you that
anyway - it was for an app that hadn't even been released for Linux.
So yeah, nominations not mentioning fixed apps or bugzilla should be
expected and accepted.

>
> Speaking of patchwork, mostly I'm fine with it. There are some
> "drawbacks" though:
>  - some duplicated time will be spent tagging "self-rejected" patches.
> I already track these based from the mailing list.
>  - it doesn't parse "Pick commit $sha, it addresses $issue"
> nominations, so it cannot substitute/replace the mailing list.
> In case my first point brought some "don't bother with the ML" type of thoughts.
>  - you don't seem to be using it [1] so I'm not sure of the sudden interest.

Patchwork can't clear any of my patches on git push. That's normal. I
do use Patchwork for reviewing patches though.

Marek