[Mesa-dev] Stable release process

[Emil Velikov]

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!

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.

Thanks
Emil

[1] The following shows ~800 "New" patches for yours ranging back to 2014.
https://patchwork.freedesktop.org/project/mesa/patches/?submitter=11032&state=&q=&archive=&delegate=