Hi!

> From: Pavel Machek <[email protected]>
> Date: Thu, 31 Aug 2017 16:47:43 +0200
>
> > Dave, Linus -- can you still take the patch?
>
> Pavel, please do not bypass maintainers like this.
>
> It's really rude, and if you do things like that instead of
> trying to work properly with us, your relationship with
> these maintainers will suffer in the long term.

Do you mean I'm being rude to Kalle, or rude to you?

In the part you snipped, Kalle asked me to do just that:

# I'm not planning to submit pull requests to 4.13 anymore. If you think
# this is so important that it needs to be applied in the last minute (I
# don't) you could always try to convince Dave to take it directly.

..and as I still believe patch should go in, that's what I did.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:

(No filename) (920.00 B)
signature.asc (181.00 B)
Digital signature Download all attachments

2017-08-31 19:59:35

Sorry for spam, I am resending in cleartext because the previous
missed the lists. Thanks Google for resetting my config when you
'upgraded'.

On Wed, 24 Oct 2018 at 09:05, Kalle Valo <[email protected]> wrote:
>
> Kalle Valo <[email protected]> writes:
>
> > Linus Torvalds <[email protected]> writes:
> >
> >> On Wed, Oct 24, 2018 at 7:01 AM Linus Torvalds
> >> <[email protected]> wrote:
> >>>
> >>> Hmm. Tentatively pulled, but there's something wrong with the Kconfig rules.
> >>
> >> Confirmed.
> >
> > BTW, our emails crossed and more info in the other email[1].
> >
> >> I did a978a5b8d83f ("net/kconfig: Make QCOM_QMI_HELPERS available when
> >> COMPILE_TEST") to fix the breakage.
> >
> > Thanks, though I don't see it yet as I guess you haven't pushed it yet.
> > Do note that it _might_ conflict the other commit which I suspect is in
> > also coming to you:
> >
> > ccfb464cd106 ("soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs")
>
> git.kernel.org is alive again for me so I can now check both commits. It
> seems that Niklas' commit[1] is more finegrained than what Linus did[2].
> I guess either of the commits should be reverted when Niklas' commit
> goes to Linus tree, or what's the best course of action?

Yes this will conflict with Niklas's patch which is part of the 4.20
pull requests. I would prefer that we revert Linus's and take
Niklas's unless there is a compelling argument to have it fixed before
-rc1. That said, if you didn't, the merge conflicts would be minor
and easily handled.

Regards,
Andy Gross

2018-10-24 13:40:24

by Linus Torvalds

[permalink] [raw]

Subject: Re: [GIT] Networking

On Wed, Oct 24, 2018 at 2:24 PM Andy Gross <[email protected]> wrote:
>
> Yes this will conflict with Niklas's patch which is part of the 4.20
> pull requests. I would prefer that we revert Linus's and take Niklas's
> unless there is a compelling argument to have it fixed before -rc1.

I have no objection to just reverting my patch when I get the real fix.

I just don't want my tree to have warnings that I see, and that may
hide new warnings coming in when I do my next pull request..

Linus