Re: [dpdk-dev] [PATCH v9 5/8] pdump: add new library for packet capturing support

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jun 15, 2016 at 11:32:39AM +0200, Thomas Monjalon wrote:
> 2016-06-15 09:05, Mcnamara, John:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > > 2016-06-14 10:38, Reshma Pattan:
> > > > The new librte_pdump library is added for packet capturing support.
> > > >
> > > 
> > > And more importantly, we need a doc in the prog guide.
> > > 
> > 
> > Hi Thomas,
> > 
> > The Programmers Guide update is in another part of the patchset. Can we get some clarification on the requirements for documentation within patchset?
> > 
> > Should all documentation related to a feature be in the patch for the feature? From your recent comments on patches it looks like that is the way you prefer it. That is fine but there is some confusion because it seems that wasn't always a requirement in the past so it would be best to clarify, and preferably document this.
> 
> When reading a patch (including after integration in the git tree),
> it is easier to understand when having the related doc with the code changes.
> 
> > Also, it makes it a bit harder for the documentation maintainer (me in this case) to see doc changes within patches and to ack just the doc part. From a documentation maintainer point of view it would be best to have any, non-trivial, doc changes in a separate patch.
> 
> I understand your concern.
> But you cannot assume every doc changes will be properly highlighted in
> the headline. I think you need to filter patches based on a content pattern:
> 	+++ b/doc/guides/

My 2c on this is that I think that non-trivial doc changes should be in separate
patches and reviewed separately. I think that changes to add a new feature to
the release notes, or to add a new tick-mark in the NIC feature matrix should
be part of the patches adding the new features. However, a multi-paragraph doc
addition I think is better as a separate doc patch.

/Bruce