From: Patrick Williams <patrick@stwcx.xyz>
To: Nancy Yuen <yuenn@google.com>
Cc: Brendan Higgins <brendanhiggins@google.com>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: C++ Feature Whitelist/Blacklist
Date: Sun, 6 Nov 2016 21:44:25 -0600 [thread overview]
Message-ID: <20161107034425.GA15757@heinlein.lan> (raw)
In-Reply-To: <CADfYTpF_MtD2v07Rmopu11_VVo0SnzTKN73A9NqyBvtsTkSE_Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
Nancy,
A few minor responses below.
On Fri, Nov 04, 2016 at 02:46:42AM -0700, Nancy Yuen wrote:
> As for fitting in the head of the contributor or maintainer, I don't think
> it's reasonable. One of the points made during our meeting was that
> openBMC should be a project other people can come in and contribute to.
> Future contributors may or may not be devoting all their time to openBMC
> and may not have the bandwidth to "fit" one of the repos in their head.
What I meant by this was not that every contributor is expected to know
all of the code, but that the maintainer is likely to know the internal
APIs of it enough to be able to review contributions. One of the main
points of contention is a proposal that "makes it easier to review" and
that is the part that makes more sense when you are talking about 1+
MLOC of interdependent code. That particular point is less interesting
when you are talking about <50kLOC.
> Btw, Google's codebase is not monolithic.
I realize that was not likely the case, but those were the words Titus
used in his public talk.
> I also want to echo Brendan's caution in his reply with regard to citing
> industry experts. [3] is not a list of do and don't dos by industry
> experts. Their abstract clearly states "Please try to verify or disprove
> rules! In particular, we'd really like to have some of our rules backed up
> with measurements or better examples"
I feel you have taken this one sentence very much out of context.
The first paragraph of the abstract says:
The C++ Core Guidelines are a collaborative effort led by Bjarne
Stroustrup, much like the C++ language itself. They are the result of
many person-years of discussion and design across a number of
organizations. Their design encourages general applicability and broad
adoption but they can be freely copied and modified to meet your
organization's needs.
They are actively encouraging others to use this list. The also state
in the abstract:
The rules are designed to be supported by an analysis tool. Violations
of rules will be flagged with references (or links) to the relevant
rule. We do not expect you to memorize all the rules before trying to
write code.
In fact, clang-tidy has a number of checks for these rules to encourage
their use.
The one sentence you quoted I read as "We are willing to change these
rules if evidence points to the contrary. Please prove us wrong." And,
in fact, the guidelines are "actively maintained" on Github and have
changed since their original introduction.
--
Patrick Williams
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2016-11-07 3:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-01 23:09 C++ Feature Whitelist/Blacklist Brendan Higgins
2016-11-02 0:53 ` Brendan Higgins
2016-11-02 17:18 ` Patrick Williams
2016-11-03 0:02 ` Brendan Higgins
2016-11-03 12:03 ` Patrick Williams
2016-11-07 10:25 ` Nancy Yuen
2016-11-07 19:57 ` Patrick Williams
2016-11-09 17:59 ` Nancy Yuen
2016-11-04 9:46 ` Nancy Yuen
2016-11-07 3:44 ` Patrick Williams [this message]
2016-11-07 10:26 ` Nancy Yuen
2016-11-07 22:37 ` Andrew Jeffery
[not found] ` <E611E1DD-010C-4F96-9368-C6265082325C@fuzziesquirrel.com>
2016-11-02 18:03 ` Brendan Higgins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161107034425.GA15757@heinlein.lan \
--to=patrick@stwcx.xyz \
--cc=brendanhiggins@google.com \
--cc=openbmc@lists.ozlabs.org \
--cc=yuenn@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.