On Fri, Jul 26, 2024 at 8:44 AM Ondrej Mosnacek [off-list ref] wrote:

On Thu, Jun 20, 2024 at 4:39 PM Paul Moore [off-list ref] wrote:

quoted

On Thu, Jun 20, 2024 at 6:03 AM Ondrej Mosnacek [off-list ref] wrote:

quoted

On Wed, Jun 19, 2024 at 4:46 AM Paul Moore [off-list ref] wrote:

quoted

On June 14, 2024 11:08:41 AM Paul Moore [off-list ref] wrote:

quoted

On Fri, Jun 14, 2024 at 3:20 AM [off-list ref] wrote:

quoted

Hello:

This series was applied to netdev/net.git (main)
by David S. Miller [off-list ref]:

Welp, that was premature based on the testing requests in the other
thread, but what's done is done.

Ondrej, please accelerate the testing if possible as this patchset now
in the netdev tree and it would be good to know if it need a fix or
reverting before the next merge window.

Ondrej, can you confirm that you are currently working on testing this
patchset as requested?

[NOTE: adding SELinux list as a FYI for potential breakage in upcoming kernels]

quoted

Not really... I tried some more to get cloud-init to work on FreeBSD,
but still no luck...

As mentioned previously, if you aren't able to fit the testing into
your automated framework, you'll need to do some manual testing to
verify the patches.

Sigh... okay, I now did test the scenario with a FreeBSD system as B
and it passed.

Great, thank you.

I'm not saying the concern is not credible or that (in general)
testing this use case is not important. What I'm missing is some
explanation/reasoning that would make me think "Oh yeah, these patches
really could break this scenario" ...

One of the challenges to network testing is that you don't always know
how other network stack implementations are going to react when you
start getting into corner cases or lesser implemented protocols.  You
just need to test your patches to make sure nothing breaks.

quoted

quoted

You see something there that I don't, and I'd like to see and
understand it, too. Let's turn it from *your* concern to *our* concern
(or lack of it) and then the cooperation will work better.

It's not about you or I, it's about all of the users who rely on this
functionality and not wanting to break things for them.

Test your patches Ondrej, if you don't you'll find me increasingly
reluctant to accept anything from you in any of the trees I look
after.

Paul, I don't want to break the kernel, but that doesn't mean I will
do an excessive amount of work for someone else when there doesn't
seem to be a logical reason to do so. IMHO, just because someone
somewhere has a special hard-to-test use case that is very important
to them doesn't mean that it is your job as a community project
maintainer to force other contributors to do work to defend these
peoples' use cases.

I have a responsibility to ensure that we provide a stable, secure,
maintainable kernel that is as bug-free as we can possibly make it.
If I see a patch that I believe warrants a certain type of test to
help meet those goals I'm going to ask for that testing.  Of course
like many things, even things we believe to be very clear, there is
always going to be a chance that disagreements will happen around what
testing is relevant or necessary.  How you handle that disagreement is
a choice you will need to make for yourself, but I would encourage you
to consider that more testing is usually a good thing, and aggravating
those who review/ACK your patches is generally not a good long term
strategy.

-- 
paul-moore.com