Re: [PATCH 2/2] staging: r8188eu: Make some clean-ups in usbctrl_vendorreq()

On Tue, 24 Aug 2021 at 17:18, Greg Kroah-Hartman
[off-list ref] wrote:

On Tue, Aug 24, 2021 at 07:04:31PM +0300, Pavel Skripkin wrote:

quoted

On 8/24/21 6:59 PM, Fabio M. De Francesco wrote:

quoted

On Tuesday, August 24, 2021 5:43:26 PM CEST Pavel Skripkin wrote:

quoted

On 8/24/21 6:39 PM, Fabio M. De Francesco wrote:

quoted

Oh, I know where it comes from... :)

quoted

It's a patch of mine that is in the queue, waiting to be

reviewed and applied.

quoted

Please see: https://lore.kernel.org/lkml/20210819221241.31987-1-fmdefrancesco@gmail.com/ (local)
oh.... there are _a lot_ of pending changes :)

I guess, we need smth like public-mirror with already reviewed and
working changes

It's becoming a serious problem. A lot of times I see people who is asked to
rebase and resend, not because they forget to fetch the current tree, instead
because the tree changes as soon as Greg start to apply the first patches in the
queue and the other patches at the end of the queue cannot be applied.

Anyway,I understand that Greg cannot apply a patch at a time soon after
submission but in the while the queue grows larger and larger.

It can be easily fixed. We need public fork somewhere (github,
git.kernel.org ...) and we should ask Greg to add remote-branch to his tree.

No, not going to happen, sorry.  I will catch up with patches when I get
the chance and then all will be fine.  This is highly unusual that there
are loads of people all working on the same staging driver.  No idea why
everyone jumped on this single one...

relax, there is no rush here...

greg k-h

Yeah I'm with Greg on this one - we don't need github forks etc, my
strategy has thus far been to just wait for staging-testing to
coalesce into a more up-to-date state and then work on top of that as
needed. Extra forks just introduce more complexity and more to watch +
keep track of in my opinion, as the e-mails still keep flowing in
anyway :-)

Regards,
Phil