From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 48EEA2B9F for ; Wed, 9 Mar 2016 12:28:39 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id l68so188191075wml.0 for ; Wed, 09 Mar 2016 03:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:organization:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=wajdmYQvv2JxkhwA8u4ijhfglckfDf+8gdoRbF3oFHc=; b=qYmKr93bv6FsqiybfQhcmikGi0xTauyqvyTi68DVCMpCiOjjDQfRkUDn8f9TCh+QtD jKqxQ6zXCgQnnVkZgP2m3lBFryRcQWdA9gCIjfJYNnyOQ3b+sIaYcK9PpFFoHkdVXU7l 16oSKPnRKxqjuTJkWdbLoRQuSpL61nH01BFdBphU3dbLuqDEOIX3VWkACfuFf6VrhDsG tXQfWhASB2kVjHbvoCZ2WDPFTYRbeOmBxIOunReVciaxdP5U0Y4ksF0oe44b8C2qu3Sc JU9TN4yWH4HCB7bKiPrJGJ5RY/qRhgpxvmCcz8yWKGMUSvW2gc00GB5kAiWuPaLCgd2c FJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=wajdmYQvv2JxkhwA8u4ijhfglckfDf+8gdoRbF3oFHc=; b=DoFVagdvacPfsDgK8tM0q7ZHBvbv970XNN52BYCQ2YJ7hm/rX5MYyEDd1yGktRNN0r ZJlNui5eOv5r5cxJqyCH8anHfy3IDFaYERxSTkQUFFDIL+IsRtvoBqmUWsjVho3j6AxB g3EzUn5bV9U9fv/8DSj7i2STKQpbh04kVBvUp3hSNH6krmW0lUYFi+vBtOpz365RdCjl foFUIAYTigJ+Q3fP035lbsHkJEiakspSRF5hqGZoG6lZoQpq4ySgKZ697eA7lHdxh00X sLnqXpZIGb+M4lWI0wAliT+4tapG1fZYrFQvjJ56N3NPYR7VsmjRDI9EzIpJgJlacOV8 XDNQ== X-Gm-Message-State: AD7BkJLWPQVWxEEXAFB1Sq+IXekLSoTy1E3IZTLPLIYvAIO6L4Wfb0usVVKmB8XKwMfh5l1n X-Received: by 10.194.21.197 with SMTP id x5mr32462506wje.90.1457522919158; Wed, 09 Mar 2016 03:28:39 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id q139sm7948355wmd.2.2016.03.09.03.28.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 03:28:37 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson , dev@dpdk.org Date: Wed, 09 Mar 2016 12:26:58 +0100 Message-ID: <2577394.tDVninKuVb@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160309110138.GB16076@bricha3-MOBL3> References: <1456469514-9103-1-git-send-email-jingjing.wu@intel.com> <3177758.3DUFdx3GZH@xps13> <20160309110138.GB16076@bricha3-MOBL3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] expectations on maintainer's review X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 11:28:39 -0000 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. 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. > 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. 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. > 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.