On 18 November 2016 at 12:34, Marek Olšák <mar...@gmail.com> wrote:
> On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov <emil.l.veli...@gmail.com>
> wrote:
>> On 17 November 2016 at 23:42, Marek Olšák <mar...@gmail.com> wrote:
>>> On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov <emil.l.veli...@gmail.com>
>>> wrote:
>>>> On 15 November 2016 at 16:57, Marek Olšák <mar...@gmail.com> wrote:
>>>>> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov <emil.l.veli...@gmail.com>
>>>>> wrote:
>>>>>> On 15 November 2016 at 16:13, Marek Olšák <mar...@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.
As mentioned in private that was due to bug on my end as I was working
on improving the workflow.
Please don't everything under the same nominator.
>>
>> 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.
>
Seems to work fairly well here. Admittedly I have way less (and
smaller) patches...
Please elaborate a bit on "We need Patchwork for mesa-stable, so that
patches don't get lost."
How you plan to use it to track/other. Can we get a clear
idea/understanding your workflow/expectations so that things work
better for all of us ?
Thanks
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
