linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/2] PCI: Document patch submission hints
Date: Mon, 30 Jul 2018 16:31:36 +0200	[thread overview]
Message-ID: <20180730143136.GA4093@wunner.de> (raw)
In-Reply-To: <20180712155946.GB28466@bhelgaas-glaptop.roam.corp.google.com>

On Thu, Jul 12, 2018 at 10:59:46AM -0500, Bjorn Helgaas wrote:
> But on reflection, I think the overall value of this writeup is
> minimal.  It's a lot of repetition of things already documented
> elsewhere and most of it boils down to "pay attention to existing
> practice and don't do things differently unless you're innovating and
> adding value."  That *should* be obvious, and if it's not, I doubt
> that adding one more thing to read is going to make it more obvious.

So my opinion is that your writeup does contain valid points that are
worth documenting:  For an open source project, a top priority is to
attract and retain contributors who improve the bus factor, who keep
the code base alive and maintained, thereby avoiding bit rot.

Knowledge diffusion, including documentation of best practices and
conventions, goes a long way towards that goal.  Your writeup was
mainly from a maintainer perspective: "consistency makes maintenance
easier".  But consistency is also valuable from a contributor
perspective:  It makes it easier to dive into a code base and find
your way around, and that includes changelogs in the git history.

There are important bits of knowledge in the writeup, if those can
be distilled, the result would very much be valuable to have in the tree.

Example:

> I generally use
> "PCI/XXX" for things in the core (mostly capabilities like MSI, AER,
> DPC, etc) and "PCI: xxx:" for drivers (shpchp, pciehp, etc).

That was in fact unknown to me.

If you find it difficult to put yourself in the shoes of a contributor,
I could try to rework the document and distill the points I find important.

Thanks,

Lukas

  reply	other threads:[~2018-07-30 14:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 20:27 [PATCH v1 0/2] PCI: Add patch submission and ACPI FW/OS info Bjorn Helgaas
2018-06-29 20:27 ` [PATCH v1 1/2] PCI: Document patch submission hints Bjorn Helgaas
2018-06-29 22:26   ` Lukas Wunner
2018-07-01 17:45   ` Lukas Wunner
2018-07-12 15:59     ` Bjorn Helgaas
2018-07-30 14:31       ` Lukas Wunner [this message]
2018-07-30 21:56         ` Bjorn Helgaas
2018-06-29 20:27 ` [PATCH v1 2/2] PCI: Document ACPI description of PCI host bridges Bjorn Helgaas
2018-07-03  4:56   ` Sinan Kaya
2018-07-03  5:15   ` Sinan Kaya
2018-07-04  9:40   ` Rafael J. Wysocki
2018-07-27 21:01     ` Bjorn Helgaas

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=20180730143136.GA4093@wunner.de \
    --to=lukas@wunner.de \
    --cc=helgaas@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).