linux-kernel - Re: [PULL for v6.6] drm-misc-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF6AEGu8mRB_wiFeWx17Z12Eu+NnP6VLFBr5sypcnxjQyj7_sQ@mail.gmail.com>
Date:   Tue, 15 Aug 2023 12:59:07 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Dave Airlie <airlied@...il.com>
Cc:     Thomas Zimmermann <tzimmermann@...e.de>,
        Daniel Vetter <daniel.vetter@...ll.ch>, daniels@...labora.com,
        robdclark@...gle.com, gustavo.padovan@...labora.com,
        guilherme.gallo@...labora.com, sergi.blanch.torne@...labora.com,
        linux-kernel@...r.kernel.org, robclark@...edesktop.org,
        david.heidelberg@...labora.com,
        Helen Mae Koike Fornazier <helen.koike@...labora.com>,
        anholt@...gle.com, dri-devel@...ts.freedesktop.org,
        emma@...olt.net, airlied@...hat.com
Subject: Re: [PULL for v6.6] drm-misc-next

On Tue, Aug 15, 2023 at 12:23 PM Dave Airlie <airlied@...il.com> 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