Thread (139 messages) 139 messages, 3 authors, 2016-03-11

Re: [PATCH 106/113] rtl8xxxu: convert rtl8723bu_init_bt() into rtl8723b_enable_rf()

From: Jes Sorensen <hidden>
Date: 2016-03-01 00:15:37

Julian Calaby [off-list ref] writes:
Hi Jes,

On Tue, Mar 1, 2016 at 10:51 AM, Jes Sorensen [off-list ref] wrote:
quoted
Julian Calaby [off-list ref] writes:
quoted
Hi Jes,

On Tue, Mar 1, 2016 at 9:05 AM,  [off-list ref] wrote:
quoted
From: Jes Sorensen <redacted>

rtl8723bu_init_bt() is effectively the function enabling RF, so name
it appropriately.
Should this be merged into the patches that introduce these functions?
Again, this would be rewriting history and simply cause me to fight a
pile of patch conflicts rebasing things, for no gain, and at the risk of
introducing new errors in the process.
Totally agree, this is definitely something that would cause conflicts.

IMHO, history is only important if multiple people have contributed to
something or it's being developed in public - which, for Linux, I
define as it being in a maintainer's repository.
Well I have to completely agree with you on that one. I have had
multiple test out my development repository while I was working on
this. I reordered some patches for an earlier submission to reduce the
patchset.
This patch set looks like you've been playing around with a bunch of
stuff, completed *bu support, then just thrown it all over the wall
without "prettying" it up for review and submission. If I were
developing this I'd have happily rewritten history even if all I did
was reduce the number of patches by squashing later fixes into earlier
patches.
Well again, prettying things up by merging a lot of patches together
reduces the maintainability and the debug option. Patches often sit
outside a maintainer's tree for a long time, and the sub-maintainer and
developer may have to go back and bisect his/her way to a bug that was
introduced in the middle.

Linux development is not only what happens in the official tree, it's
also how it got there.
I can see a lot of scope for reducing the number of patches in this
patch set, so if you'd like me to play around with that, just ask.
Unless you plan to test every single change you suggest against all the
supported USB parts, then I'd say thanks, but no thanks.

The whole point of git is to commit often, and keep the history.

Jes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help