From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.1500.1611258705755414445 for ; Thu, 21 Jan 2021 11:51:46 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VzAxF08c; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611258704; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+KnOsn5RrNlTQULJ1BHtTdT/lNifvJO/a+KWM3b+7rI=; b=VzAxF08cemIxrQk95uZwRa5rs/NlyLXRG5HsGK4Jbc4yjeMRGhvSnbLV/IGJE9x68bj2IO lghNlu1Qi4HoAP7336CtUQSymo5CoYvzC0YRJrxPnUkUSq2IuzYpha4S/gDcyBV6wVZvl2 iUXDwM45JLiV7+h2a8Dx6AGKxqO/WDI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-423-Q_aS5XtrOHSXY6zF3sFGXg-1; Thu, 21 Jan 2021 14:51:42 -0500 X-MC-Unique: Q_aS5XtrOHSXY6zF3sFGXg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 017B01800D41; Thu, 21 Jan 2021 19:51:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-169.ams2.redhat.com [10.36.115.169]) by smtp.corp.redhat.com (Postfix) with ESMTP id 97DB136FA; Thu, 21 Jan 2021 19:51:38 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v4 0/9] support CPU hot-unplug To: Ankur Arora , devel@edk2.groups.io Cc: imammedo@redhat.com, boris.ostrovsky@oracle.com References: <20210118063457.358581-1-ankur.a.arora@oracle.com> <5d932166-9413-d195-230f-8d7c9a70aa2e@oracle.com> <668b5faa-5c8b-97b5-f679-a431768d4f94@redhat.com> <07470a7e-1e9c-e950-ae72-1e5ec45f22c7@oracle.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 21 Jan 2021 20:51:37 +0100 MIME-Version: 1.0 In-Reply-To: <07470a7e-1e9c-e950-ae72-1e5ec45f22c7@oracle.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/21/21 20:11, Ankur Arora wrote: > On 2021-01-21 4:29 a.m., Laszlo Ersek wrote: >> For catching such issues early on, please run "PatchCheck.py" before >> posting, e.g. as in: >> >> $ python3 BaseTools/Scripts/PatchCheck.py master..topic_branch >> >> (In the present case, PatchCheck reports lots of "not CRLF" errors.) >> > > PatchCheck.py is great. Thanks. > >> >> An even better idea is to push your topic branch (which you're about to >> post to the list) to your edk2 fork on github.com, and then submit a >> pull request against the "tianocore/edk2" project. The pull request will >> be auto-closed in the end (it will never be merged), but the goal is to >> trigger a CI run on the patch set, and to give you the error messages if >> any. PatchCheck runs as a part of CI, too. >> >> (github.com PRs are used for actual merging by edk2 maintainers, but for >> that, they set the "push" label on the subject PRs, and the "push" label >> is restricted to maintainers.) >> >> I apologize about the extra delay. Would you be OK posting v5? > > Sure. Thanks for your understanding, I'm relieved. > Just a side question which I should have asked you earlier: are > the coding standards listed somewhere? Yes, see "C Coding Standards" at . Although... > I had looked for answers to similar questions but the "TianoCore C style > guide" doesn't mention either PatchCheck.py or rules around CRLF. ... you may have found exactly that, already. Unfortunately, like all documentation in the world, this document is somewhat out of date. There is also a tool, called ECC, that contains a builtin C language parser, that enforces various style requirements. It's built into the CI system and runs on github -- however, we have it disabled for OVMF, in commit ef3e73c6a0c0 ("OvmfPkg: Disable EccCheck CI until EccCheck issues are fixed", 2020-12-14). There are two reasons for that: - Some stuff that ECC enforces is just overzealous -- in some cases, we relax the coding style under OvmfPkg specifically, but ECC cannot easily be configured to tolerate those relaxations (for example, you cannot configure it to ignore a particular error code *regardless* of where it occurs under OvmfPkg). - In some cases, ECC rejects C language constructs that are both valid and conformant to the coding style (i.e., ECC has its own bugs). So we usually "teach" these quirks to contributors during review. It's quite a lot of investment, which is part of why we hope that contributors stick around. An alternative is this: in your topic branch that you intend to post to edk2-devel, include an *extra* patch (not to be posted to the list) that *reverts* commit ef3e73c6a0c0. And submit a github.com PR with this variant of your topic branch. As a result, ECC will be unleashed on (the end-stage of) your patch series. If you fix all of the ECC issues, then reviewers should make next to zero *style* complaints -- on the other hand, you could be updating code that ECC complains about *incorrectly* (due to an ECC bug, or because the subject style rule is something we deem superfluous, or at least "possible to bend", under OvmfPkg). So perhaps try to investigate this latter avenue, and see if you are willing to deal with what ECC throws at you. :) > Thanks for the comments and my apologies for making you review all of > these non-substantive changes. It's a standard part of reviewing the first few contributions of a new community member; it's too bad we don't have better stuff in place. We do have docs but they are slightly outdated, and we do have ECC but with warts. We also have recommendations (not official requirements!) on setting up git, as a part of -- which is likely out of date somewhat --; the BaseTools/Scripts/SetupGit.py utility automates more or less the same settings. We also have BaseTools/Scripts/GetMaintainer.py which lets you determine the Cc:'s you should put in each commit message... And when you dump all this *process* on a new contributor, they run away screaming -- kind of justifiedly. :/ Thanks Laszlo