In D54817#1294097, @kp wrote:

In D54817#1294095, @lwhsu wrote:

Maybe we should rename ai-policy to ai-note. During the many and length meetings, discussions, a "policy" cannot please everyone.

The current situation and the truth is that people are already using it, and we can't stop them. A strong "NO" will just let some people lie and pretend not using it, or worse, we lost some good contributions.

I simply do not understand this argument. We can indeed not 100% guarantee that no one would commit LLM generated code if we stated an explicit policy against this.
But neither can we guarantee that no one would commit copyright infringing code, but we still have a strong policy against it.

Maybe we should rename ai-policy to ai-note. During the many and length meetings, discussions, a "policy" cannot please anyone.

In D56354#1289604, @se wrote:

The tests complete in 3 seconds on my amd64 system.
I do assume that the 100 times slower execition on riscv64 is due to inefficient emulation of that platform?
Instead of patching the timeout in individual ports, I believe the parameters in the CI system should be adjusted to account for the slow execution speed of emulated systems.
Therefore, I do not want to set the timeout to such a high value for all platforms.
If there is consensus that changing individual ports is required, I'd make the timeout adjustment depend on the architecture (apparently, only riscv64 is affected).

Usually I'm not a fan of increasing timeout but I think we should do it in this case.

@oshogbo I think you can commit this, as you're earlier than the patch is created to https://bugs.freebsd.org/286702 , btw, the current policy is that the cross-repo commit is encouraged and no really need explicitly approval. Of course, asking review is still encouraged, just like in any repository.

The only thing we need more is bump the PORTREVISION.

See also: https://bugs.freebsd.org/286702

This one should be in the list of blanket approval.

In D55893#1278897, @kib wrote:

For now, I suggest to #ifdef 0 the ADD_TEST(), then revert it when the updated test is written.

Does this need MFC?

Quick response:

I'm good for kmods part. For dhcpd, in general it's a good direction. It's a bit pity that we lost the message of needing "ISC dhcp server", as I am not sure if this test works with other dhcpd. Not sure where is the best place to put that information.

Please also put PR: 260891 in the commit message.

This one is done in D42612

ref: https://bugs.freebsd.org/292982

I believe this is fine, for the formal process, maybe it's nice to add this on behalf of srcmgr

Thanks!

I haven't added the ci build, but I assume this has been tested. We may also want to mention gcc15 at https://docs.freebsd.org/en/articles/committers-guide/#_current_compiler_versions

WWW: information?

Do we still need to info of GH_TUPLE in distinfo file?

In D54877#1254532, @bz wrote:

You can normally just commit these. I never ask for review. I think people are just happy if it happens for as long as we don't break the syntax ;-) Thank you!

That's good, then we can have fu540 support longer.

In D54421#1249144, @mhorne wrote:

Bump to latest v1.8.1 and bump fu540 u-boot revision

Just go as the corss-repo commit is encouraged now? BTW this builds fine in my poudriere (all flavors).