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]
Date:   Wed, 11 May 2022 13:06:23 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Dave Airlie <airlied@...il.com>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Daniel Vetter <daniel@...ll.ch>,
        Jonathan Corbet <corbet@....net>, Sean Paul <sean@...rly.run>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        freedreno <freedreno@...ts.freedesktop.org>
Subject: Re: Adding CI results to the kernel tree was Re: [RFC v2] drm/msm:
 Add initial ci/ subdirectory

On Wed, May 11, 2022 at 12:08 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Wed, May 11, 2022 at 11:40 AM Rob Clark <robdclark@...il.com> wrote:
> >
> > It is missing in this revision of the RFC, but the intention is to
> > have the gitlab-ci.yml point to a specific commit SHA in the
> > gfx-ci/drm-ci[1] tree, to solve the problem of keeping the results in
> > sync with the expectations.  Ie. a kernel commit would control moving
> > to a new version of i-g-t (and eventually deqp and/or piglit), and at
> > the same time make any necessary updates in the expectations files.
>
> Wouldn't it then be better to just have the expectation files in the
> ci tree too?

The main reason is that we would frequently have situations where both
-next and -fixes pointing at the same ci tree commit, but with
differing expectations.  If we kept the expectations in the ci tree,
we'd end up frequently updating the ci tree and then updating the
kernel tree to point to the appropriate ci tree version.

Additionally, on the mesa side, it has been useful to squash the
expectations update into the commit that fixed a bug or added a
feature.  It provides a connection in git history between code and
test results.

BR,
-R

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ