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 at 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
