Julian Calaby <julian.calaby@xxxxxxxxx> writes: > Hi Jes, > > On Tue, Mar 1, 2016 at 10:51 AM, Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> wrote: >> Julian Calaby <julian.calaby@xxxxxxxxx> writes: >>> Hi Jes, >>> >>> On Tue, Mar 1, 2016 at 9:05 AM, <Jes.Sorensen@xxxxxxxxxx> wrote: >>>> From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> >>>> >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
