From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] expectations on maintainer's review
Date: Wed, 9 Mar 2016 14:15:04 +0000 [thread overview]
Message-ID: <20160309141502.GA15892@bricha3-MOBL3> (raw)
In-Reply-To: <2577394.tDVninKuVb@xps13>
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?
Regards,
/Bruce
next prev parent reply other threads:[~2016-03-09 14:15 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 [this message]
2016-03-09 14:19 ` Thomas Monjalon
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=20160309141502.GA15892@bricha3-MOBL3 \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.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;
as well as URLs for NNTP newsgroup(s).