From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=SA0vOUF2; spf=pass (domain: linaro.org, ip: 209.85.128.67, mailfrom: leif.lindholm@linaro.org) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by groups.io with SMTP; Thu, 19 Sep 2019 13:27:23 -0700 Received: by mail-wm1-f67.google.com with SMTP id b24so5466693wmj.5 for ; Thu, 19 Sep 2019 13:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=LzGEvU8cMDbsNWCdlMiBLmAg1+8ooYBOWtMqsz14GGU=; b=SA0vOUF2jRguPCgpYZS8PFCAnWj/1Bku2GUXgiaVfCbRASpyZ+nrO7tKp4/odOmoqw lqpun+Z+fSwVgH4hI9uzlwktpuR1xWAZKt6O+WFqjhSMR63RxeEZBJSQzt+dbu6OHvyx tZ1OlvpzU8uElE3i9L0GcRMpAHL811oTaxN6U1iv5nHHAf9E277hryFwHZVcWYU+ZiXT toR0V1N1LXalT3a3CMPXw9sTG++22OnKuDmfM1530HuMdgzWa/y9BsPtsmOSgl1tK/CF cOM/MHTwJ4O1sJOhSN/M09q843+ZEm/nW9T3i+bi1wkc1X6MsbuDVG6qBOyXHsYbQpM1 EbKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=LzGEvU8cMDbsNWCdlMiBLmAg1+8ooYBOWtMqsz14GGU=; b=tUT4hRACwRk1aecYdcqK+cKvkA0z8NpMwsrrioSatLndTOisNaZbEmFAcZ3+HZ6xL/ 2n8qqpZvVkr4W+GDo8IKRH4cXCYhQlvM3hBaCXGbxF4Bu3qxQXkEaFpa172gVhWb8EzB zQj3bXPWVlij9CsztJRoNkZy6EfhFxyVopGYxCIajtLDW5wLrLKDQ3irJNzLq1z9LvSi xuQSfHdF2tDbhVFokg/X1ra6w1fnE4hv9+0duqgpP/g0T5oXxbU57i4sX126Kh7+gsOX JiQhMXiw8gUn31PQt3/Ul0cxKefUW7QqvQbxB9VZtiLxH4pIu2wcepiUsd+NdEVhNY6I z5IQ== X-Gm-Message-State: APjAAAVPU8VTMExqHP32I3Y9Hz204MX+tuhmQ791ykGNK0Vy94YgAHUb wSRyX8k9swDW5IzRsUm2J0yw2Q== X-Google-Smtp-Source: APXvYqyWl3qAr1VO2wWOIGMoPooJHL+7tZBk16vbe5+GWcjm6NV9LguNURLs33jpy4jYPqQTUyacNg== X-Received: by 2002:a1c:1d8d:: with SMTP id d135mr4503440wmd.7.1568924841929; Thu, 19 Sep 2019 13:27:21 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id y186sm12878705wmb.41.2019.09.19.13.27.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Sep 2019 13:27:21 -0700 (PDT) Date: Thu, 19 Sep 2019 21:27:19 +0100 From: "Leif Lindholm" To: Laszlo Ersek Cc: devel@edk2.groups.io, "Gao, Liming" , Baptiste Gerondeau , "ard.biesheuvel@linaro.org" , "Kinney, Michael D" , "Zhang, Shenglei" Subject: Re: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio Message-ID: <20190919202719.GB28454@bivouac.eciton.net> References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4FE630@SHSMSX104.ccr.corp.intel.com> <20190919094450.GN28454@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 19, 2019 at 09:24:15PM +0200, Laszlo Ersek wrote: > On 09/19/19 11:44, Leif Lindholm wrote: > > I agree with this as a general rule, but for this (hopefully never to > > be repeated) operation, it makes sense to me to keep each change in > > this set as one patch. > > > > For the simple reason that the alternative leaves several unusable > > commits in sequence in the repository. There is simply no way to > > bisect through this change on a per-package basis. > > > > This is after all a horrible horrible hack that lets us keep using the > > .asm files provided for one toolchain family (RVCT) in a different > > toolchain family (MSFT), without having to delete and re-add, losing > > history in the process. > > > > Would you be OK with an exception for this extremely unusual > > situation? > > (The question was posed to Liming, but I'm going to follow up here with > my own thoughts, after getting CC'd by Liming. Thanks for that BTW.) Yes, I should have thought of that myself - Baptiste did exactly what I asked him to. > Let's assume the changes are split up with a fine granularity. Under > that assumption, consider two cases: > > (1) ARM builds on Visual Studio are broken until the last patch is > applied, but all other toolchains continue working fine throughout the > series. > > versus > > (2) ARM builds are broken on Visual Studio *and* on at least one other > -- preexistent -- toolchain, until the last patch in the series is applied. > > > Which case reflects reality? > > If it's case (1), then I prefer the fine-grained patch series structure. > Nothing regresses with existent toolchains (so bisection works with > them), we just have to advertise the last patch in the series as the one > that enables Visual Studio. > > If it's case (2), then I agree with the larger (multi-package) patch, as > a rare exception. > > (We can also put it like this: if it's *possible* to write this series > such that it enables (1), then we should strive for that.) I agree with your logic. It's just that I'm not even aware of anyone who has *tried* building with RVCT for several years. So we leave the "probably not working" toolchain potentially working for a few more commits, as a tradeoff against enabling the new one in one go. (Now, fair, there are other issues with the VS ARM port that as per the cover letter will also need to be addressed before the port is fully functional.) / Leif