On Fri, Nov 18, 2016 at 4:56 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> 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.
OK.
>
>>>
>>> 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."
I thought Patchwork would help us to prevent losing patches. If you
have a different (just as good) process in place already, Patchwork is
not necessary.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
