From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26D92C433FE for ; Wed, 11 May 2022 19:08:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346625AbiEKTI1 (ORCPT ); Wed, 11 May 2022 15:08:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243793AbiEKTIZ (ORCPT ); Wed, 11 May 2022 15:08:25 -0400 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBB766D19F for ; Wed, 11 May 2022 12:08:23 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id dk23so5915367ejb.8 for ; Wed, 11 May 2022 12:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vmamqcS6UVefjf9ZEAc++snoGPnFlkAJ7A2gr6Hybu0=; b=dBuK2lymrrDPdlannsOQHXnUcfuHTrBkOPfEbu7qkW0E5kYO5Z+bFsewwOP9kO18lS Ebs/5hwuDtsE7odsW2FMFSxqELyAfsWmglvZotYHMj+VC+iTD8HgUjirJo2F71hfTMdW r33xYQIIdwMLG8WV5P6snakQvBwy2w3VlziQA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vmamqcS6UVefjf9ZEAc++snoGPnFlkAJ7A2gr6Hybu0=; b=pS1+8M3p3Inp8yemNtlVkVPAGWgg3XMM0VKTm0qSAcj86lhBo+Fvgj6+Xs2y/wfV8D cmaRjiHBv5s4SpmQt7VpNgfsenzHVRO6PM51wzo3iYVSn1gbQGDmugZvPdtcsefiXQh3 dKww3KYL5qsOC4FMD4poDWCjs3OQM5W09z93Wtxn2PLZZVwRNmXiq2n2oqvdzBdwj/ib GZRhhvA9booYYFckfg3gildrgc4y0zt7/XaUp/iewlz0GaVQ88nI/2zpmdVwoUf1XMJz d7EouoH5jKmWICcVdyOHOFTxrKI8ui2qLyiTnONCkHTAOSSeaVJm5T14KMO25/4SXxvN mKTA== X-Gm-Message-State: AOAM532t1eG+J/3SZW3Z6yEeuuNr1sMFg+ganuKZ7bkBn6qiXhWUrLum xNim1b9/RgE+TZHLQcPkAK5rxr0EXf6LAGlRIqY= X-Google-Smtp-Source: ABdhPJyXivkxti7l+gz/wbfbhfSCTIyrG8ALlw4s23FyfUe6KXYZUc5zPr99VVyoK+siD3nL8/Pj7w== X-Received: by 2002:a17:907:8693:b0:6f8:635a:1d32 with SMTP id qa19-20020a170907869300b006f8635a1d32mr20830881ejc.663.1652296102128; Wed, 11 May 2022 12:08:22 -0700 (PDT) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com. [209.85.128.46]) by smtp.gmail.com with ESMTPSA id m3-20020a170906848300b006f3ef214dc6sm1266679ejx.44.2022.05.11.12.08.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 12:08:20 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id r188-20020a1c44c5000000b003946c466c17so1169404wma.4 for ; Wed, 11 May 2022 12:08:19 -0700 (PDT) X-Received: by 2002:a05:600c:4f06:b0:394:836b:1552 with SMTP id l6-20020a05600c4f0600b00394836b1552mr6316930wmq.145.1652296099201; Wed, 11 May 2022 12:08:19 -0700 (PDT) MIME-Version: 1.0 References: <20220510070140.45407-1-tomeu.vizoso@collabora.com> <20220510141329.54414-1-tomeu.vizoso@collabora.com> In-Reply-To: From: Linus Torvalds Date: Wed, 11 May 2022 12:08:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Adding CI results to the kernel tree was Re: [RFC v2] drm/msm: Add initial ci/ subdirectory To: Rob Clark Cc: Dave Airlie , Tomeu Vizoso , Greg Kroah-Hartman , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Daniel Vetter , Jonathan Corbet , Sean Paul , Abhinav Kumar , "open list:DOCUMENTATION" , linux-arm-msm , LKML , dri-devel , freedreno Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Wed, May 11, 2022 at 11:40 AM Rob Clark 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 kernel tree might have just the expected *failures* listed, if there are any. Presumably the ci tree has to have the expected results anyway, so what's the advantage of listing non-failures? Linus