[dpdk-dev,v2] doc: update contribution guideline for dependent work

Message ID 20180109154402.85731-1-ferruh.yigit@intel.com (mailing list archive)
State Rejected, archived
Delegated to: Thomas Monjalon
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation fail apply issues

Commit Message

Ferruh Yigit Jan. 9, 2018, 3:44 p.m. UTC
  Changing some part of the libraries but not updating all dependent code
cause maintenance problems.

The update in the contribution guide practically suggest updating all
dependent code.

With the counter argument that sometimes it is not possible to know
details of the dependent code and this prevents improvements, an
exception left for the cases dependent code requires special expertise,
for those cases it is possible left dependent code unchanged with the
condition to not break the existing code. The dependent code maintainer
should do the required update later.

For the cases it is possible to update the dependent code but it
requires extra work, it is expected from author of the original patch to
do that extra work and update dependencies.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>

---
This is a process related update, cc'ing tech board for more comment.
Cc: techboard@dpdk.org

v2: reworded as suggested.
---
 doc/guides/contributing/patches.rst | 3 +++
 1 file changed, 3 insertions(+)
  

Comments

Thomas Monjalon May 24, 2018, 4:58 p.m. UTC | #1
09/01/2018 16:44, Ferruh Yigit:
> +* If changes effect other parts of the project, update all those parts as well unless updating requires special knowledge.
> +  For the cases where not all the effected code is updated, the submitter should ensure that changes don't break existing code.

We should review it again in the technical board.
I think we should encourage asking for help to complete a patch
with community's help.
  
Ferruh Yigit April 5, 2019, 3 p.m. UTC | #2
On 5/24/2018 5:58 PM, Thomas Monjalon wrote:
> 09/01/2018 16:44, Ferruh Yigit:
>> +* If changes effect other parts of the project, update all those parts as well unless updating requires special knowledge.
>> +  For the cases where not all the effected code is updated, the submitter should ensure that changes don't break existing code.
> 
> We should review it again in the technical board.
> I think we should encourage asking for help to complete a patch
> with community's help.

self-nack

This was process update patch, but it seems lack of consensus for now.
  
Ferruh Yigit April 5, 2019, 3:02 p.m. UTC | #3
On 4/5/2019 4:00 PM, Ferruh Yigit wrote:
> On 5/24/2018 5:58 PM, Thomas Monjalon wrote:
>> 09/01/2018 16:44, Ferruh Yigit:
>>> +* If changes effect other parts of the project, update all those parts as well unless updating requires special knowledge.
>>> +  For the cases where not all the effected code is updated, the submitter should ensure that changes don't break existing code.
>>
>> We should review it again in the technical board.
>> I think we should encourage asking for help to complete a patch
>> with community's help.
> 
> self-nack
> 
> This was process update patch, but it seems lack of consensus for now.
> 

for reference, mentioned patch:
https://patches.dpdk.org/patch/33250/
  

Patch

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 64408e788..6ed43be04 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -153,6 +153,9 @@  Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
 * Don't break compilation between commits with forward dependencies in a patchset.
   Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing.
 
+* If changes effect other parts of the project, update all those parts as well unless updating requires special knowledge.
+  For the cases where not all the effected code is updated, the submitter should ensure that changes don't break existing code.
+
 * Add tests to the the ``app/test`` unit test framework where possible.
 
 * Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.