From: Marcus Wolf <marcus.wolf@smarthome-wolf.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: devel@driverdev.osuosl.org, gregkh@linuxfoundation.org,
linux@Wolf-Entwicklungen.de, linux-kernel@vger.kernel.org,
"Simon Sandström" <simon@nikanor.nu>
Subject: Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h
Date: Mon, 4 Dec 2017 22:21:16 +0200 [thread overview]
Message-ID: <b7e6f4b5-5aa6-a2cb-40d2-a9859489db8c@smarthome-wolf.de> (raw)
In-Reply-To: <20171204195613.amlez432beq72t7j@mwanda>
Am 04.12.2017 um 21:56 schrieb Dan Carpenter:
> On Mon, Dec 04, 2017 at 09:31:06PM +0200, Marcus Wolf wrote:
>>>> Then it might be, that DATAMODUL_MODE_PACKET might need an other value.
>>>
>>> That's future code so we can delete that sentence for now.
>>
>> With the rule above, you are absolutely right. But we now spend time, to
>> remove an currently non necessary feature ("double layer"), which will take
>> time to re-introduce as soon, as someone wants to support a second chip.
>> Isn't that double-work and a thus a pitty?
>>
>
> It is what it is... In the kernel we insist all code have a user right
> now when it's merged. Unused code or future code is deleted. We hate
> abstraction layers. Everyone argues that their abstraction layer is
> different and good but kernel devs instinctively hate abstraction.
>
> To be honest, in the kernel we do do a lot of work twice. I made people
> redo 9 quite large patches for this pi4333 driver today. And they're
> probably going end up conflicting and have to be redone again... :/
> That does suck. I don't know what to do about it.
>
> In my view it helps that people sending patches don't ever have to worry
> about future code and we can focus on what exists now. Greg will never
> reject code for "future reasons" unless the future is almost right away
> like tomorrow or maybe the next day.
>
> regards,
> dan carpenter
>
Hi Dan,
I am self employed and controling two small companies. For me it is very
important to do efficient work - otherwise the 24 hours of a day are too
short to get my work done, even if I include the night.
The goal of most projects (my own, as well as my customers) is very
clear, but normaly you are not able to reach it in one pass. Therefore
projects are split up in parts and try to release parts, to be on market
earlier.
No one would accept, if I would optimise a software for a current
release in a way, that I close doors for the final goal.
So I agree: We can't change the rules and have to take them as they are.
But if I read your lines, it's shaking me. I observed this sending the
patch over and over again and it realy bugs me. Not beacause it might be
boring, mainly because for me it feels like a huge waste of time - time
I simply don't have.
Same applies to removing stuff, when I already now, (at least for my
products) I will need it in future.
Maybe controlling a straup, developing fancy new products, the market
likes to have (and in a time, the market is accepting you to present
them) and contributing to the kernel need that different kind of mind
set, that it's dam hard to do both at the same time.
Cheers,
Marcus
next prev parent reply other threads:[~2017-12-04 20:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-03 15:17 [PATCH 0/6] Fix indentation and CamelCase issues in staging/pi433 Simon Sandström
2017-12-03 15:17 ` [PATCH 1/6] staging: pi433: Fix indentation in rf69_enum.h Simon Sandström
2017-12-03 15:17 ` [PATCH 2/6] staging: pi433: Capitalize constant definitions Simon Sandström
2017-12-03 15:17 ` [PATCH 3/6] staging: pi433: Rename variable in struct pi433_rx_cfg Simon Sandström
2017-12-03 15:17 ` [PATCH 4/6] staging: pi433: Rename enum optionOnOff in rf69_enum.h Simon Sandström
2017-12-03 16:49 ` Marcus Wolf
2017-12-04 10:04 ` Simon Sandström
2017-12-04 10:17 ` Dan Carpenter
2017-12-04 10:37 ` Dan Carpenter
2017-12-04 18:37 ` Marcus Wolf
2017-12-04 19:15 ` Dan Carpenter
2017-12-04 19:22 ` Marcus Wolf
2017-12-04 19:42 ` Simon Sandström
2017-12-04 19:59 ` Marcus Wolf
2017-12-04 20:05 ` Simon Sandström
2017-12-05 12:06 ` Marcus Wolf
2017-12-05 12:16 ` Dan Carpenter
2017-12-05 12:40 ` Marcus Wolf
2017-12-05 13:03 ` Dan Carpenter
2017-12-03 15:17 ` [PATCH 5/6] staging: pi433: Rename enum dataMode " Simon Sandström
2017-12-04 10:24 ` Dan Carpenter
2017-12-04 19:12 ` Marcus Wolf
2017-12-04 19:21 ` Dan Carpenter
2017-12-04 19:31 ` Marcus Wolf
2017-12-04 19:56 ` Dan Carpenter
2017-12-04 20:21 ` Marcus Wolf [this message]
2017-12-03 15:17 ` [PATCH 6/6] staging: pi433: Rename enum modShaping " Simon Sandström
2017-12-04 10:33 ` Dan Carpenter
2017-12-04 18:59 ` Marcus Wolf
2017-12-04 19:18 ` Dan Carpenter
2017-12-04 19:41 ` Marcus Wolf
2017-12-17 17:13 ` Marcus Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7e6f4b5-5aa6-a2cb-40d2-a9859489db8c@smarthome-wolf.de \
--to=marcus.wolf@smarthome-wolf.de \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@Wolf-Entwicklungen.de \
--cc=simon@nikanor.nu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®