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] [day] [month] [year] [list]

Message-ID: <dcff3281-9d38-a244-4844-1633039a9076@suse.de>
Date:   Thu, 17 Aug 2023 15:38:17 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Rob Clark <robdclark@...il.com>, Dave Airlie <airlied@...il.com>
Cc:     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

Hi

Am 15.08.23 um 21:59 schrieb Rob Clark:
> 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..

I saw that this patchset has been reviewed on dri-devel. If you don't 
want it to go through DRM misc, I guess it should really be pulled into 
drm-next directly.

Do you plan to set up auto-CI for DRM misc branches? (Sorry if this 
question has been answered before.)

Best regards
Thomas

> 
> BR,
> -R

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)