From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::232; helo=mail-io0-x232.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EF15822631464 for ; Mon, 12 Mar 2018 05:17:11 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id f1so11215492iob.0 for ; Mon, 12 Mar 2018 05:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FJupjVaE0UI4sU21QdhwrQ22xPsY7mmZamBzSXwfR70=; b=ARm+qb/CF4Xcz8W/X6Yc/KnbggxltfJdQ2cr9H0h3NIYT/wItvFFQ/iM8HNlG/X5Iz +b1aG5gq9o+4RLTDWiyPhxSDoIeRadCab7v58J1ZFQd23tggrn/R0VhDTeu6dNwjWqai mOiGEnVlSPmPyyZWMSOFnSWnojjx5lpzH+/Dc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJupjVaE0UI4sU21QdhwrQ22xPsY7mmZamBzSXwfR70=; b=FYaHK4BtoSKUhBOuQMosDlg2FtRl+xBKdssAo/1lxE5CXoUsbWG0a5HnVI2y74XsY/ 4f6ctHI9gQFjK8L5aiE+SfAh93OqvrT/zV/4GQg3a4SoKclv4bgBArFen5n+wiWBaRWE tVS9qBSk0VPOoq5Tf75blYaD59yajTwxSAJxlz6DnRABy96PYSuld1q2A3r2qifjewDC exSprkZGnYPPMSPch1vHo8mpyVIcNqjP9BvDV2xCbxPGs7aMfk2FOBeT3wivqc85zZeS jkzzzN7gR0UQfrFoBhfyiQhPCjD8mwdkSJoJBI1p/ROHbbL5FIcyJzoM+z+R8/1f60t4 tWZA== X-Gm-Message-State: AElRT7G9rZNgEnEQGcEBgEOobgXNtxInn6qKHjrHvQNeWbGSZVwg+3PU /ANviG8rmJBTNhQAcaICGw3bDLYHXnE4BKHL/1grzQ== X-Google-Smtp-Source: AG47ELt+gjAumRXaTuCqpzpIkm6imTy5dDv2Sn+QAbLlNACUtmjeZoSF5WMMQ8j3nm3HHU3qzzVF66dTFkL/9KelZtE= X-Received: by 10.107.41.16 with SMTP id p16mr8538694iop.173.1520857411681; Mon, 12 Mar 2018 05:23:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Mon, 12 Mar 2018 05:23:30 -0700 (PDT) In-Reply-To: References: <20180311014926.3049-1-lersek@redhat.com> <20157fd6-a776-fe10-6492-55e85ec03b3f@redhat.com> From: Ard Biesheuvel Date: Mon, 12 Mar 2018 12:23:30 +0000 Message-ID: To: Laszlo Ersek Cc: edk2-devel-01 , Anthony Perard , Brijesh Singh , Jordan Justen , Julien Grall , Phil Dennis-Jordan Subject: Re: [PATCH 00/45] ArmVirtPkg, OvmfPkg: list module-internal headers in INF files X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 12:17:12 -0000 Content-Type: text/plain; charset="UTF-8" On 12 March 2018 at 12:06, Laszlo Ersek wrote: > On 03/11/18 12:54, Ard Biesheuvel wrote: > >> I am merely saying that it is not always necessary to share your >> personal journey resulting in the patches at this level of detail, >> simply because it doesn't scale. > > Doesn't scale for me, or doesn't scale for reviewers? > > If the latter, do you suggest that I keep such detailed notes out of the > v1 posting as well? (Because, I imagine, if I edit them down for v2 > only, then I may have wasted reviewer time already.) > > The recurrent bottleneck for me is trying to figure out what this or > that part of the patch was meant to solve, and why that way. I've also > encouraged contributors to capture their exact scenario / use case in > commit messages; the more specific the better. (IIRC, one example is > commit f5404a3eba1d, "OvmfPkg: Increase the maximum size for > Authenticated variables", 2016-03-25.) IOW, I tend to find the focus too > wide, and the information lacking. > > However, if I end up wasting your time instead of saving it, then I'm > doing it wrong. I wrote up the commit messages the way I did because I > thought it would save time for me, if I had to review the patches (I > tend to verify patches maybe a bit too pedantically too, and I > appreciate when the commit messages give me crutches for that). If it > has the opposite effect on you, then I'm doing it wrong. > >> In any case, I am happy with this to go in as is, if you prefer. >> >> Reviewed-by: Ard Biesheuvel > > Thank you -- peeking ahead at Jordan's review as well, I think I'll save > you guys another round of this. > > I'm honestly confused now about how I should word my future commit > messages. Therefore I can't simply promise "I'll keep them short"; I > might not know *how* (i.e. what to leave out). I'll need to actively > work on that. > The issue you are addressing is the fact that changes to header files will not trigger rebuilds if they are not listed in the module's .INF file. So while I fully expect you to confirm that any .h files you add to those .INF files are in fact depended upon, a reviewer or other 'consumer' of the patch is highly unlikely to be interested in reading novels about how each individual .h file is used exactly, and simply dropping the unused ones and adding the used ones should suffice. As I see it, the commit log should explain the rationale of the change, not a stream-of-consciousness account of how it came into being (and I know I am exaggerating here, but only to clarify the distinction)