On Tue, Aug 15, 2023 at 12:23 PM Dave Airlie <airlied@xxxxxxxxx> wrote:
Otherwise, there should be something like a drm-ci tree, from which you
can fetch the changes directly.
I asked for a pull request so that I could also merge it to msm-next
so that I can do CI this cycle. (Unlike the earlier out-of-tree
version of the drm/ci yml, this version needs to be in the branch that
CI runs on, so I can't use the workaround that I had in previous
cycles.)
Perhaps it should be a pull request targeting drm-next instead of drm-misc-next.
We were going to do this one-off for this cycle and then evaluate
going forward whether a drm-ci-next tree is needed. But perhaps it is
a good idea.
I'm still not 100% sure how this is going down, and I'm meant to be off today,
Don't send this as patches to drm-misc-next, but I think we'd want
this in drm-next for a cycle before sending it to Linus, but maybe
it's not directly interfering with the kernel so it's fine
Ideally when the real merge window opens and drm-next is merged I'd
want to have a branch + PR written for this against drm-next that I
can send to Linus separately and see how it goes.
The tricky thing is we need this patch in-tree to run CI in the first
place.. so soak time in drm-next on it's own isn't hugely useful. (Or
at least I'd need to move msm-next forward to drm-next for it to be
useful.)
I guess that is a bit of an advantage to the earlier approach that
kept everything but the expectation files in a different git tree..
BR,
-R
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature