| Message ID | 1367426477-10441-1-git-send-email-gerlando.falauto@keymile.com |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Gerlando Falauto <gerlando.falauto@keymile.com> Date: Wed, 1 May 2013 18:41:17 +0200 > Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com> > --- > Changes from v3: > * Added "and break a long line" to the commit message > Changes from v2: > * Split cosmetic (this patch) from functional changes (next patch) Never resubmit patches by themselves, always resubmit the entire series. Because when one patch has problems, I toss the entire series from patchwork, and by resubmitting the entire series again you are also giving me important information, you're telling me that the subsequent patches in the series still apply cleanly even though the first one has changed. I've tossed this patch too, resubmit this properly, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 05/01/2013 07:16 PM, David Miller wrote: > From: Gerlando Falauto <gerlando.falauto@keymile.com> > Date: Wed, 1 May 2013 18:41:17 +0200 > >> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com> >> --- >> Changes from v3: >> * Added "and break a long line" to the commit message >> Changes from v2: >> * Split cosmetic (this patch) from functional changes (next patch) > > Never resubmit patches by themselves, always resubmit the entire series. I was just wondering what happens in that case, thank you for the explanation, I had no idea. > > Because when one patch has problems, I toss the entire series from patchwork, Is "v3b" good or shall I just use v4 instead? Do I also need to change the version number (and add "Changes from previous version" lines) to the subsequent patches, even though nothing has actually changed)? Should have I used a cover letter to begin with? > and by resubmitting the entire series again you are also giving me important > information, you're telling me that the subsequent patches in the series > still apply cleanly even though the first one has changed. That I don't understand. I thought it would be the other way around, that's why I resubmitted only the one which changed. If I resubmit the entire series, how can you tell patches 2 and 3 are identical to the previous version I posted? Last question: Is chain reply OK? Thanks for your patience, Gerlando > > I've tossed this patch too, resubmit this properly, thanks. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Gerlando Falauto <gerlando.falauto@keymile.com> Date: Wed, 01 May 2013 19:35:09 +0200 > That I don't understand. I thought it would be the other way around, > that's why I resubmitted only the one which changed. Any patch you submit I assume you test applied yourself successfully, therefore by submitting it you are saying that you validated them as a series explicitly or know that the other patches have no conflicts. Also, please never submit new versions of patches in replies to older patch discussions. Chain replies in order to construct a series are OK, especially when you provide a proper "[PATCH 0/N] ..." initial posting explaining the series. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 05/01/2013 07:43 PM, David Miller wrote: > From: Gerlando Falauto <gerlando.falauto@keymile.com> > Date: Wed, 01 May 2013 19:35:09 +0200 > >> That I don't understand. I thought it would be the other way around, >> that's why I resubmitted only the one which changed. > > Any patch you submit I assume you test applied yourself successfully, > therefore by submitting it you are saying that you validated them > as a series explicitly or know that the other patches have no conflicts. I understand, you're right. I hope adding "Changes from v(n-1): None" should also be enough to say that further review should not be necessary as the patch is identical to the previous version. > Also, please never submit new versions of patches in replies to older > patch discussions. > > Chain replies in order to construct a series are OK, especially when > you provide a proper "[PATCH 0/N] ..." initial posting explaining > the series. > OK, thanks. Gerlando -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c index 2655c9f..8438e01 100644 --- a/net/tipc/bcast.c +++ b/net/tipc/bcast.c @@ -584,8 +584,7 @@ static int tipc_bcbearer_send(struct sk_buff *buf, { int bp_index; - /* - * Prepare broadcast link message for reliable transmission, + /* Prepare broadcast link message for reliable transmission, * if first time trying to send it; * preparation is skipped for broadcast link protocol messages * since they are sent in an unreliable manner and don't need it @@ -613,11 +612,12 @@ static int tipc_bcbearer_send(struct sk_buff *buf, struct tipc_bearer *s = bcbearer->bpairs[bp_index].secondary; if (!p) - break; /* no more bearers to try */ + break; /* No more bearers to try */ - tipc_nmap_diff(&bcbearer->remains, &p->nodes, &bcbearer->remains_new); + tipc_nmap_diff(&bcbearer->remains, &p->nodes, + &bcbearer->remains_new); if (bcbearer->remains_new.count == bcbearer->remains.count) - continue; /* bearer pair doesn't add anything */ + continue; /* Nothing added by bearer pair */ if (!tipc_bearer_blocked(p)) tipc_bearer_send(p, buf, &p->media->bcast_addr); @@ -628,13 +628,14 @@ static int tipc_bcbearer_send(struct sk_buff *buf, /* unable to send on either bearer */ continue; + /* Swap bearers for next packet */ if (s) { bcbearer->bpairs[bp_index].primary = s; bcbearer->bpairs[bp_index].secondary = p; } if (bcbearer->remains_new.count == 0) - break; /* all targets reached */ + break; /* All targets reached */ bcbearer->remains = bcbearer->remains_new; }
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com> --- Changes from v3: * Added "and break a long line" to the commit message Changes from v2: * Split cosmetic (this patch) from functional changes (next patch) net/tipc/bcast.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)