: General remarks on patch submission

Folks,

please allow a few general comments to avoid further misunderstandings and complications.

Several of you are more from a research background than from a developer background. The diversity on this list often creates communication differences which have a paralysing effect on progress:

* often a patch submission breaks out into a discussion thread which continues for weeks and months, while the the patch meanwhile "brews" unchanged somewhere;

* often parties defend their arguments from a wide range of diverse perspectives:
o the draft/specification perspective;
o one's own research agenda;
o network safety;
o operational stability of the implementation.
Within one's scope one is of course right, but the perspectives are not all compatible.

* One can only one thing at a time: research discussions or fixing implementation problems. There is only one time budget for both activities.

In short:
==== * My patches are all well-documented, are in chunks of a single logical change per patch, and I do
much to make the patch reviewing as straightforward as possible. I don't know if you will get that on other lists; in any case what I am asking for in return is that these patches are dealt with fairly and with reference directly to the code, and less global research questions.

* While I try my best to cooperate information-wise, I simply don't have the time to participate in long discussion threads (especially when triggered by just a few lines of code). If there is group-wise agreement, I'll be happy to update the patch set if a majority of people support an update they have agreed on, but I would like to limit discussion to the code content of patches.

* I will accept / fix / and track down every single technical implementation issue which someone points out to me in a patch. I am not insisting on accepting second-class material, but I want a fair review for the material which has indeed cost hard work.

To illustrate what I mean, here are the last patch statistics (since March):

 Documentation/networking/dccp.txt   |   22    19     3     0
 include/linux/dccp.h                |   67    42    25     0 +-
 net/dccp/ackvec.c                   |    4     2     2     0
 net/dccp/ccids/Kconfig              |   12     8     4     0
 net/dccp/ccids/ccid2.c              |    2     1     1     0
 net/dccp/ccids/ccid3.c              |  867   322   545     0 +++++++++++++-----------------------
 net/dccp/ccids/ccid3.h              |   83    44    39     0 +--
 net/dccp/ccids/lib/Makefile         |    3     2     1     0
 net/dccp/ccids/lib/loss_interval.c  |  238   140    98     0 +++++----
 net/dccp/ccids/lib/loss_interval.h  |   74    46    28     0 +--
 net/dccp/ccids/lib/packet_history.c |  455   327   128     0 +++++++++++++-----
 net/dccp/ccids/lib/packet_history.h |  210   116    94     0 ++++----
 net/dccp/ccids/lib/tfrc.h           |   30    26     4     0 +
 net/dccp/ccids/lib/tfrc_module.c    |   44    44     0     0 +
 net/dccp/dccp.h                     |   33    27     6     0 +
 net/dccp/input.c                    |  129    81    48     0 +++--
 net/dccp/minisocks.c                |    1     0     1     0
 net/dccp/options.c                  |   62    30    32     0 +-
 net/dccp/output.c                   |   75    50    25     0 ++-
 net/dccp/proto.c                    |  176   119    57     0 ++++---
 net/dccp/sysctl.c                   |   10    10     0     0
 21 files changed, 1456 insertions(+), 1141 deletions(-)

There are almost as many deletions as insertions (in CCID3 the factor is close to 2).

Which means that this work is conservative, mostly dumb, clerical review-type.
I am not complaining, but such work - fishing out all the bugs - is required to obtain a useable stack.

I last discovered this when writing a simple socket application - that bombed out, which lead to the patches on closing/termination state; which in turn lead to the patches regarding the Sync-floods.

This is Linux. People are free to do what they want and how they want it. It's up to the maintainer to decide what is bullshit comments and time wasting and what is useful.

I sometimes go on but I do so because I believe in things strongly. I've struggled to get my code in at times at the past and others like Arnaldo and David have told me bluntly when I'm wrong and I just feel stupid rather than blaming them.

So in short just because you get pissed off with the likes of things that Eddie and I say I'm not going to change a damn thing. Look in the mirror. I appreciate all the work that you've done and think you've moved CCID3 forward more than me but this sort of email is totally unneeded. Lean to work with the Linux community.

Ian

Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group