[MPTCP] Fwd: Re: Few questions about submitting patches

[MPTCP] Fwd: Re: Few questions about submitting patches

[Rao Shoaib]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

There has been some misunderstanding on what an RFC patch is and what 
standards it needs to meet. Following is the official response of David 
Miller.

Based on those guidelines the RFC patch we submitted meets and exceeds 
the requirements. So please review it. Replacement of function pointers 
will be addressed later as a separate issue.

In case there are other procedural issues that would prohibit technical 
discussion please site the written rules or first ask David Miller.

There are a lot of technical issues to discuss, so if possible lets not 
get tied up on process and bureaucracy. Looking forward to detailed 
technical comments.

Shoaib


-------- Forwarded Message --------
Subject: 	Re: Few questions about submitting patches
Date: 	Wed, 21 Mar 2018 12:46:17 -0400 (EDT)
From: 	David Miller <davem(a)davemloft.net>
To: 	rao.shoaib(a)oracle.com
CC: 	netdev(a)vger.kernel.org, eric.dumazet(a)gmail.com



From: Rao Shoaib <rao.shoaib(a)oracle.com>
Date: Wed, 21 Mar 2018 09:41:13 -0700

> I am new to Linux. I would like to understand the rules and etiquettes
> of engaging with the community. I have read the materials that I could
> find. As I work with Linux I come across situations for which I can
> not seem to find any answers. Hopefully folks on the list can answer
> them.
> 
> * Submitting an RFC Patch
> 
> As I understand, an RFC patch is submitted to solicit comments and is
> not for inclusion. Is it sufficient for an RFC patch to have the
> correct coding style and compile, or does it need more? For example,
> If the patch consists of a series of patches, does each patch have to
> compile independently etc etc.

It should build and function, unless you explicitly state that the
patch is not build nor functionally tested and is intended to show
the design of the change.

> * #ifdef FOO
> 
> In a regular patch consisting of a series of patches, can the above
> #ifdef be used in a patch before the patch that allows the selection
> of FOO. That patch is part of the series but comes later.

It is better to introduce them at the same time.

But if it is prohibitively difficult to do so, yet at the same
time properly split up your changes into manageable pieces, it
can be OK.

It is definitely determined on a case by case basis.


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3837 bytes --]

Re: [MPTCP] Fwd: Re: Few questions about submitting patches

[Rao Shoaib]

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]



On 03/26/2018 06:27 PM, Mat Martineau wrote:
>
> Hi Rao -
>
> On Wed, 21 Mar 2018, Rao Shoaib wrote:
>
>>
>> There has been some misunderstanding on what an RFC patch is and what 
>> standards it needs to meet. Following is the official response of David
>> Miller.
>>
>> Based on those guidelines the RFC patch we submitted meets and 
>> exceeds the requirements. So please review it. Replacement of 
>> function pointers
>> will be addressed later as a separate issue.
>
> Given what David has said, I still think it's better to structure the 
> patch set according to the guidelines I pointed to before. Required? 
> No, but I think it's worth the effort. You might not agree, and that's 
> ok.
>
> I know at least one other community member is taking a look at the 
> first version of your patches. You mentioned that you are reworking 
> your changes to invoke MPTCP functions using macros instead of 
> indirect calls, so my personal plan is to take a closer look after you 
> post v2.
I am not planning to submit version 2. Dealing with function pointers is 
a separate and straight forward issue so please review the current patch 
as it is.

Thanks,

Shoaib

>
>>
>> In case there are other procedural issues that would prohibit 
>> technical discussion please site the written rules or first ask David 
>> Miller.
>>
>> There are a lot of technical issues to discuss, so if possible lets 
>> not get tied up on process and bureaucracy. Looking forward to detailed
>> technical comments.
>>
>
> In my experience, a lot of the work involved in getting patches merged 
> has been the unglamourous stuff to get the patches set up for review 
> and upstreaming. My goal has been to help others and pass on that 
> knowledge. But, to be clear, I'm not waiting for review based on the 
> patch set structural changes, I want to look at everything in context 
> with the macro/indirect call changes.

>
> Thanks,
>
> Mat
>
>
>>
>>
>> -------- Forwarded Message --------
>> Subject:
>> Re: Few questions about submitting patches
>> Date:
>> Wed, 21 Mar 2018 12:46:17 -0400 (EDT)
>> From:
>> David Miller <davem(a)davemloft.net>
>> To:
>> rao.shoaib(a)oracle.com
>> CC:
>> netdev(a)vger.kernel.org, eric.dumazet(a)gmail.com
>>
>> From: Rao Shoaib <rao.shoaib(a)oracle.com>
>> Date: Wed, 21 Mar 2018 09:41:13 -0700
>>
>> > I am new to Linux. I would like to understand the rules and etiquettes
>> > of engaging with the community. I have read the materials that I could
>> > find. As I work with Linux I come across situations for which I can
>> > not seem to find any answers. Hopefully folks on the list can answer
>> > them.
>> > > * Submitting an RFC Patch
>> > > As I understand, an RFC patch is submitted to solicit comments 
>> and is
>> > not for inclusion. Is it sufficient for an RFC patch to have the
>> > correct coding style and compile, or does it need more? For example,
>> > If the patch consists of a series of patches, does each patch have to
>> > compile independently etc etc.
>>
>> It should build and function, unless you explicitly state that the
>> patch is not build nor functionally tested and is intended to show
>> the design of the change.
>>
>> > * #ifdef FOO
>> > > In a regular patch consisting of a series of patches, can the above
>> > #ifdef be used in a patch before the patch that allows the selection
>> > of FOO. That patch is part of the series but comes later.
>>
>> It is better to introduce them at the same time.
>>
>> But if it is prohibitively difficult to do so, yet at the same
>> time properly split up your changes into manageable pieces, it
>> can be OK.
>>
>> It is definitely determined on a case by case basis.
>>
>>
>
> -- 
> Mat Martineau
> Intel OTC

Re: [MPTCP] Fwd: Re: Few questions about submitting patches

[Mat Martineau]

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]


Hi Rao -

On Wed, 21 Mar 2018, Rao Shoaib wrote:

> 
> There has been some misunderstanding on what an RFC patch is and what standards it needs to meet. Following is the official response of David
> Miller.
>
> Based on those guidelines the RFC patch we submitted meets and exceeds the requirements. So please review it. Replacement of function pointers
> will be addressed later as a separate issue.

Given what David has said, I still think it's better to structure the 
patch set according to the guidelines I pointed to before. Required? No, 
but I think it's worth the effort. You might not agree, and that's ok.

I know at least one other community member is taking a look at the first 
version of your patches. You mentioned that you are reworking your changes 
to invoke MPTCP functions using macros instead of indirect calls, so my 
personal plan is to take a closer look after you post v2.

> 
> In case there are other procedural issues that would prohibit technical discussion please site the written rules or first ask David Miller.
> 
> There are a lot of technical issues to discuss, so if possible lets not get tied up on process and bureaucracy. Looking forward to detailed
> technical comments.
>

In my experience, a lot of the work involved in getting patches merged has 
been the unglamourous stuff to get the patches set up for review and 
upstreaming. My goal has been to help others and pass on that knowledge. 
But, to be clear, I'm not waiting for review based on the patch set 
structural changes, I want to look at everything in context with the 
macro/indirect call changes.

Thanks,

Mat


> 
> 
> -------- Forwarded Message --------
> Subject:
> Re: Few questions about submitting patches
> Date:
> Wed, 21 Mar 2018 12:46:17 -0400 (EDT)
> From:
> David Miller <davem(a)davemloft.net>
> To:
> rao.shoaib(a)oracle.com
> CC:
> netdev(a)vger.kernel.org, eric.dumazet(a)gmail.com
> 
> From: Rao Shoaib <rao.shoaib(a)oracle.com>
> Date: Wed, 21 Mar 2018 09:41:13 -0700
> 
> > I am new to Linux. I would like to understand the rules and etiquettes
> > of engaging with the community. I have read the materials that I could
> > find. As I work with Linux I come across situations for which I can
> > not seem to find any answers. Hopefully folks on the list can answer
> > them.
> > 
> > * Submitting an RFC Patch
> > 
> > As I understand, an RFC patch is submitted to solicit comments and is
> > not for inclusion. Is it sufficient for an RFC patch to have the
> > correct coding style and compile, or does it need more? For example,
> > If the patch consists of a series of patches, does each patch have to
> > compile independently etc etc.
> 
> It should build and function, unless you explicitly state that the
> patch is not build nor functionally tested and is intended to show
> the design of the change.
> 
> > * #ifdef FOO
> > 
> > In a regular patch consisting of a series of patches, can the above
> > #ifdef be used in a patch before the patch that allows the selection
> > of FOO. That patch is part of the series but comes later.
> 
> It is better to introduce them at the same time.
> 
> But if it is prohibitively difficult to do so, yet at the same
> time properly split up your changes into manageable pieces, it
> can be OK.
> 
> It is definitely determined on a case by case basis.
> 
>

--
Mat Martineau
Intel OTC

Re: [MPTCP] Fwd: Re: Few questions about submitting patches

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 3064 bytes --]

Hi Rao,

On Wed, Mar 21, 2018 at 6:01 PM, Rao Shoaib <rao.shoaib(a)oracle.com> wrote:

> There has been some misunderstanding on what an RFC patch is and what
> standards it needs to meet. Following is the official response of David
> Miller.
>
Thank you for this forwarded message.

> Based on those guidelines the RFC patch we submitted meets and exceeds the
> requirements. So please review it.
>
I don't have the same experiences as some other here but I will try to give
interesting comments if I have some.
Was the version you sent last month with 9 patches the last one?

> Replacement of function pointers will be addressed later as a separate
> issue.
>
I agree about that.

> In case there are other procedural issues that would prohibit technical
> discussion please site the written rules or first ask David Miller.
>
> There are a lot of technical issues to discuss, so if possible lets not
> get tied up on process and bureaucracy. Looking forward to detailed
> technical comments.
>
Good idea.

> -------- Forwarded Message --------
> Subject: Re: Few questions about submitting patches
> Date: Wed, 21 Mar 2018 12:46:17 -0400 (EDT)
> From: David Miller <davem(a)davemloft.net> <davem(a)davemloft.net>
> To: rao.shoaib(a)oracle.com
> CC: netdev(a)vger.kernel.org, eric.dumazet(a)gmail.com
>
> > * #ifdef FOO
> >
> > In a regular patch consisting of a series of patches, can the above
> > #ifdef be used in a patch before the patch that allows the selection
> > of FOO. That patch is part of the series but comes later.
>
> It is better to introduce them at the same time.
>
> But if it is prohibitively difficult to do so, yet at the same
> time properly split up your changes into manageable pieces, it
> can be OK.
>
> It is definitely determined on a case by case basis.
>
> So ok to keep them to clearly indicate where MPTCP specific code will be?

Matthieu
-- 
[image: Tessares SA] <http://www.tessares.net> Matthieu Baerts | R&D
Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
<https://www.google.com/maps?q=1+Avenue+Jean+Monnet,+1348+Ottignies-Louvain-la-Neuve,+Belgium>

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7320 bytes --]