Date:   Wed, 29 May 2019 10:20:42 +0000
From:   Kevin 'ldir' Darbyshire-Bryant <ldir@...byshire-bryant.me.uk>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v5] net: sched: Introduce act_ctinfo action

In fairness to everyone the below deserves a public answer:

> On 27 May 2019, at 21:56, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> 
> Kevin 'ldir' Darbyshire-Bryant <ldir@...byshire-bryant.me.uk> writes:
> 
>> I have to call it a day. I have no idea why the patches are becoming
>> corrupt and hence how to fix it, it’s probably something Apple has
>> done to git, or maybe MS to my email server.
> 
> Or maybe it's just that your editor saves things with the wrong type of
> line ending (if you're on a Mac)?

It turns out everything is ok at my end.  Toke and I worked off list to establish
where the problem was located.

> 
>> Sadly I also think that the only way this patch/functionality will
>> ever be acceptable is if someone else writes it, where they or their
>> company can take the credit/blame.
> 
> Not sure why you would think so.
> 
>> I tried very hard to approach the process of upstream submission in a
>> positive way, seeking advice & guidance in the form of RFC patches,
>> many rounds later I feel they’re further away from acceptance than
>> ever.
> 
> Not sure why you'd think that either; I thought you were rather close,
> actually...
> 
>> Clearly it is not desired functionality/code otherwise it would have
>> been written by now and I cannot face another 3 rounds of the same
>> thing for act_ctinfo user space, the x_tables/nf_tables kernel helper
>> to store the DSCP in the first place and the user space code to handle
>> that.
>> 
>> As a rank outsider, amateur coder I shall leave it that I’ve found the
>> process completely discouraging. The professionals are of course paid
>> to deal with this.
> 
> It's up to you if you want to continue, of course; but honestly, I'm not
> actually sure what it is you are finding hard to "deal with"? No one has
> told you "go away, this is junk"; you've gotten a few suggestions for
> improvements, most of which you have already fixed. So what, exactly, is
> the problem? :)

The above deserves an answer.  The bottom line is that I was extremely frustrated
by what I perceived as an endless set of changing requirements and nitpicks.
I find coding hard.  Coding for upstream is harder, it *should* be.  Each
iteration of this module has required testing, backporting to 4.14 & 4.19 for more
testing on some real devices running openwrt.  Each iteration affecting netlink
parameters has also required changing & testing the (yet to be submitted) user
space code, simply to prove I haven’t screwed up the module in some way.

The changes, the backports, the testing, the checking with checkpatch, the checking
of things not checked by checkpatch (christmas trees), the whole git format-patch/
send-email (and to whom) dance, leads to a hoped for expectation on every submissing
that ‘maybe this is the one’ - to have hopes dashed by another set of ‘your email
doesn’t work’ (false positive) and another ‘adjustment of goalposts’.  It felt
like there was no end to it…and it’s bl**dy exhausting!  I’m back to coding is hard :-)

I found the most encouraging thing written in the last response was “I thought you
were rather close”, ie. keep going.  It is hard for me, like the coding, to take an
absence of “this code is ***” as a positive thing especially in the context of
“this goalpost isn’t quite the correct shade of heliotrope” I (mis?)interpret it as
all negative.  Anyway, I blew up because of frustration and feeling discouraged.

I’m a little more encouraged now but I still live in fear of the great maintainer
decreeing “thine code is a pile of poo, thine idea is a stupid, never darken this
land of linux again…fool!”  Well you get the idea ;-)


Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

Powered by blists - more mailing lists