DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] expectations on maintainer's review
Date: Wed, 09 Mar 2016 15:19:03 +0100	[thread overview]
Message-ID: <22099678.GLQKFP5REF@xps13> (raw)
In-Reply-To: <20160309141502.GA15892@bricha3-MOBL3>

2016-03-09 14:15, Bruce Richardson:
> On Wed, Mar 09, 2016 at 12:26:58PM +0100, Thomas Monjalon wrote:
> > I've changed the title for this discussion.
> > 
> > 2016-03-09 11:01, Bruce Richardson:
> > [snip comments about minor issue in release notes]
> > 
> > > Your question, though, does bring up the issue of scope and reviews again. I, as
> > > committer, spend a lot of time tweaking commit messages, sanity checking
> > > patches for compilation errors under various settings, and running checkpatch
> > > etc. before applying them. However, IMHO it is up to the maintainers of the
> > > various subsystems to enforce proper documentation in the patches submitted.
> > > The maintainers are the primary gatekeepers here, and I, for one, don't want to
> > > end up having to review all patches in detail before I apply them - otherwise
> > > we'll be limited to a very small number of driver patches per release :)
> > 
> > Yes that's a problem.
> > 
> > > In this case, if the submitter of the patch and the maintainer of the driver in
> > > question are happy with the documentation, then who am I to go querying that. :-)
> > > 
> > > Having committers do full review on apply will only have two possible effects:
> > > 1. make the maintainers less conscientious about their job, since they know the
> > >   committers will catch any real bugs or issues on apply
> > 
> > Yes we need maintainers to be conscientious on every parts of the patches.
> 
> Definite +1
> 
> > One problem about the release notes and doc, is that not a lot of maintainers
> > have the "english skills".
> > Note that it would be easier if we would allow to write in Irish, Chinese or
> > French languages ;)
> > Unfortunately we took the constraints of writing in C and English.
> > 
> 
> Yes, language is a good point, and I'm ok with helping to clean up grammar and 
> minor language issues e.g. the one word correction I suggested at the start of
> this discussion. For the scope of the text, and whether it contains enough
> information, I would tend to push that responsibility back on the maintainer
> though.
> 
> 
> > > 2. cause a lot of problems for submitters as they see a lot of issues being
> > >   flagged at the last minute by committers, when they thought their patch was
> > >   safely acked and ready for commit for some time.
> > > 
> > > We certainly see lots of the second issue occurring right now, I believe - [I'm
> > > obvously not going to comment on the former :-)]
> > > 
> > > I'd be very much in favour of having a rule that once a patch is acked by a
> > > maintainer, then it must be applied. We may suffer a bit from slightly lower
> > > quality patches getting applied, but the speed of applying patches should
> > > increase, and the patch contents can always be fixed by subsequent patches later.
> > > [Unlike commit message which can't be fixed later without rewriting git history]
> > > In this case, I feel that phrase "the perfect is the enemy of the good" applies.
> > > https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
> > 
> > Yes but I don't think saying we are OK to decrease the quality is a good message.
> > The reality is that people never rework what was been committed.
> 
> Yes, point taken.
> 
> > That's why we must be very careful on API and documentation.
> > About the release notes, decreasing its quality mean we don't care wether it is
> > read and understood. So maybe we can shrink it to less details and have only a
> > title with a git/author reference.
> 
> I don't think I agree with that. I think the doc should be readable independently
> of having the git repo.
> 
> > 
> > > Just my 2c on this. I'm sure you have a different view, Thomas, so it's probably
> > > a discussion worth having.
> > 
> > Thanks for bringing the discussion.
> 
> Indeed. So I would summarise this as:
> * an ask to the maintainers to pay increased attention to documentation side of
> patches when reviewing and acking.
> * on my end, I will do some doc reviews as part of applying commits, but on a
> best-effort basis. The primary responsibility is with the maintainers to ensure
> documentation quantity before patch application stage.
> 
> Does that seem reasonable?

Yes and I'd like to hear some maintainers to comment or commit this summary.

  reply	other threads:[~2016-03-09 14:20 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13 12:31 [dpdk-dev] [PATCH 0/2] i40evf: support interrupt based pf reset request Jingjing Wu
2016-01-13 12:31 ` [dpdk-dev] [PATCH 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-01-13 12:31 ` [dpdk-dev] [PATCH 2/2] i40evf: support interrupt based pf reset request Jingjing Wu
2016-01-27  1:49 ` [dpdk-dev] [PATCH v2 0/2] " Jingjing Wu
2016-01-27  1:49   ` [dpdk-dev] [PATCH v2 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-01-29  7:28     ` Tao, Zhe
2016-02-14  2:22       ` Wu, Jingjing
2016-02-22  7:26     ` Zhang, Helin
2016-01-27  1:49   ` [dpdk-dev] [PATCH v2 2/2] i40evf: support interrupt based pf reset request Jingjing Wu
2016-01-27  8:34     ` David Marchand
2016-02-14  3:25       ` Wu, Jingjing
2016-02-15 13:16         ` David Marchand
2016-02-18  4:06           ` Zhe Tao
2016-02-19  5:51           ` Wu, Jingjing
2016-01-28  7:03     ` Tao, Zhe
2016-02-14  2:12       ` Wu, Jingjing
2016-01-29  8:50     ` Tao, Zhe
2016-02-14  3:04       ` Wu, Jingjing
2016-02-22  8:26     ` Zhang, Helin
2016-02-26  6:51   ` [dpdk-dev] [PATCH v3 0/2] i40evf: pf reset event report Jingjing Wu
2016-02-26  6:51     ` [dpdk-dev] [PATCH v3 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-02-26  8:12       ` Zhang, Helin
2016-02-26  6:51     ` [dpdk-dev] [PATCH v3 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-02-26  8:13       ` Zhang, Helin
2016-03-08 17:44     ` [dpdk-dev] [PATCH v3 0/2] i40evf: pf reset event report Bruce Richardson
2016-03-09  3:08     ` Zhe Tao
2016-03-09  6:00     ` [dpdk-dev] [PATCH v4 " Jingjing Wu
2016-03-09  6:00       ` [dpdk-dev] [PATCH v4 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-03-09  6:00       ` [dpdk-dev] [PATCH v4 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-03-09  9:59         ` Thomas Monjalon
2016-03-09 11:01           ` Bruce Richardson
2016-03-09 11:26             ` [dpdk-dev] expectations on maintainer's review Thomas Monjalon
2016-03-09 14:15               ` Bruce Richardson
2016-03-09 14:19                 ` Thomas Monjalon [this message]
2016-03-10  3:41       ` [dpdk-dev] [PATCH v5 0/2] i40evf: pf reset event report Jingjing Wu
2016-03-10  3:41         ` [dpdk-dev] [PATCH v5 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-03-14 12:21           ` Bruce Richardson
2016-03-10  3:41         ` [dpdk-dev] [PATCH v5 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-03-15  1:59         ` [dpdk-dev] [PATCH v6 0/2] i40evf: pf reset event report Jingjing Wu
2016-03-15  1:59           ` [dpdk-dev] [PATCH v6 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-03-15  1:59           ` [dpdk-dev] [PATCH v6 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-03-22 15:13           ` [dpdk-dev] [PATCH v6 0/2] i40evf: pf reset event report Bruce Richardson

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=22099678.GLQKFP5REF@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.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).