On 18.11.2016 16:56, Emil Velikov 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.
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...
Patchwork is pretty dumb about how it compares patches. If you have
non-standard git diff settings (e.g. more lines of context), it will
never recognize a patch.
Nicolai
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
