public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: Huang Ying <ying.huang@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Andi Kleen <ak@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5 -v2] acpi, apei, Document for APEI
Date: Tue, 15 Dec 2009 23:32:16 -0500 (EST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0912152322110.6885@localhost.localdomain> (raw)
In-Reply-To: <1260780295.12561.118.camel@yhuang-dev.sh.intel.com>

On Mon, 14 Dec 2009, Huang Ying wrote:

> On Sat, 2009-12-12 at 00:58 +0800, Bjorn Helgaas wrote: 
> > On Thursday 10 December 2009 12:17:04 am Huang Ying wrote:
> > > Add document for APEI, including kernel parameters and EINJ debug file
> > > sytem interface.
> > 
> > From a stylistic point of view, I think it's better if the
> > documentation is added by the same patch that adds the functionality.
> > Having them in separate patches means there's a point in time where
> > the tree contains the functionality but not the documentation, or
> > vice versa.
> 
> Sounds reasonable, I will change this.

I don't mind if the documentation preceeds or follows the code
in a patch series.  Personally, I'd probably put it in its own
patch like you did just as a lazy way to keep the patches small.
Anybody looking at this code will be looking at the whole series
and it isn't as if documentation is going to break bisect...

What I do mind from a patch submitting style point of view
is to start a series with [PATCH 2/5 -v2].

Please start with 0/5 explaining the difference between v1 and v2;
and then number staring with 1, not 2; else at first glance,
everybody thinks that the most important patch is missing...

That said, all this code is under its own config option,
making it relatively low risk.  The question is if there
would be a significant benefit to merging this code upstream
while we know there is still going to be some significant
movement in this area before it is fully baked...

(that would be another thing to describe in 0/5...)

thanks,
-Len Brown, Intel Open Source Technology Center

  reply	other threads:[~2009-12-16  4:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-10  7:17 [PATCH 5/5 -v2] acpi, apei, Document for APEI Huang Ying
2009-12-11 16:58 ` Bjorn Helgaas
2009-12-14  8:44   ` Huang Ying
2009-12-16  4:32     ` Len Brown [this message]
2009-12-16  4:55       ` Huang Ying

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=alpine.LFD.2.00.0912152322110.6885@localhost.localdomain \
    --to=lenb@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox