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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06AB9C3F2CE for ; Sat, 29 Feb 2020 10:14:46 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DC6242468E for ; Sat, 29 Feb 2020 10:14:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC6242468E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F11696E2E1; Sat, 29 Feb 2020 10:14:43 +0000 (UTC) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by gabe.freedesktop.org (Postfix) with ESMTPS id 881976EF39; Fri, 28 Feb 2020 11:02:44 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: kusma) with ESMTPSA id 8117329695C Message-ID: <6761e107fda6af2f70f0a11784e182dfbc61cb0e.camel@collabora.com> Subject: Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services From: Erik Faye-Lund To: Daniel Stone Date: Fri, 28 Feb 2020 12:02:34 +0100 In-Reply-To: References: <6d2ec570f957b4504fb70e0b1f0632712a99dc0c.camel@collabora.com> User-Agent: Evolution 3.34.1-2 MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 29 Feb 2020 10:13:17 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: amd-gfx list , Daniel Vetter , intel-gfx , "X.Org development" , dri-devel , wayland , "X.Org Foundation Board" , Xorg Members List , Mesa Dev , gstreamer-devel@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 2020-02-28 at 10:43 +0000, Daniel Stone wrote: > On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund > wrote: > > On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: > > > Yeah, changes on vulkan drivers or backend compilers should be > > > fairly > > > sandboxed. > > > > > > We also have tools that only work for intel stuff, that should > > > never > > > trigger anything on other people's HW. > > > > > > Could something be worked out using the tags? > > > > I think so! We have the pre-defined environment variable > > CI_MERGE_REQUEST_LABELS, and we can do variable conditions: > > > > https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables > > > > That sounds like a pretty neat middle-ground to me. I just hope > > that > > new pipelines are triggered if new labels are added, because not > > everyone is allowed to set labels, and sometimes people forget... > > There's also this which is somewhat more robust: > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 > > I'm not sure it's more robust, but yeah that a useful tool too. The reason I'm skeptical about the robustness is that we'll miss testing if this misses a path. That can of course be fixed by testing everything once things are in master, and fixing up that list when something breaks on master. The person who wrote a change knows more about the intricacies of the changes than a computer will ever do. But humans are also good at making mistakes, so I'm not sure which one is better. Maybe the union of both? As long as we have both rigorous testing after something landed in master (doesn't nessecarily need to happen right after, but for now that's probably fine), as well as a reasonable heuristic for what testing is needed pre-merge, I think we're good. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel