Optimising maintainer's time

[Kalle Valo <kvalo@codeaurora.org>]

(Was "Re: [PATCH v4 0/9] rtlwifi: btcoex: Add 8822b btcoex support" but
I'll change the title to get more visibility as this is a general advice
for everyone)

Pkshih <pkshih@realtek.com> writes:

> I would like to send v5 to change the order of this patchset like:
> =C2=A0 rtlwifi: btcoex: remove comments that are not meaningful
> =C2=A0 rtlwifi: btcoex: Add modifier const to version related variables
> =C2=A0 rtlwifi: btcoex: Add struct members to replace global varaibles
> =C2=A0 rtlwifi: btcoex: Remove global variables of chip specific context
>
> =C2=A0 rtlwifi: btcoex: Add 8822b1ant coex files
> =C2=A0 rtlwifi: btcoex: Add 8822b2ant coex files
> =C2=A0 rtlwifi: btcoex: Add 8822b header files to precomp.h
> =C2=A0 rtlwifi: btcoex: Add 8822b to Makefile
> =C2=A0 rtlwifi: btcoex: Add 8822b routine to btc interfaces
>
> Then, you can review patches 1/9 - 4/9 that refine btcoex, and the
> remaining 8822b's btcoex can review later. Does it work for you?

I have forgotten the details already so I can't really comment about
this patchset.

But what I can say is that you need to consider maintainer's time, it's
usually limited (all maintainers are busy). If my time is abused (in
networking terms) there will be bufferbloat and I need to start doing
fair queing, and nobody wants that :)

So whenever you are submitting patches consider how you can most
effectively optimise maintainer's time (size of patches, quality of
code, following the rules etc). When you do that, over time you will
notice that your patches get applied faster. But if you do the opposite,
you will notice that it takes longer and harder to get your patches in.

--=20
Kalle Valo