Isuru Fernando

> Additionally in those cases where the CI does provide a false positive it is unlikely that the maintainers will catch it. This doesn't take into account that maintainers know...

`extra=forbid` is wrong for all of these. I'd like to support new platforms without changing conda-smithy.

> @isuruf Can we even support new platforms without touching conda-smithy at all? Probably yes, as it would generate the matching .ci_support files already? Thus, would you be happy if...

I recently fixed a small bug in conda-build to support new platforms without explicitly adding the new platforms. Works just fine afterwards.

No, the linter is still failing. We have to move these specific errors to warnings.

> Why does the linter need to go through? To make automerging go through.

I don't understand why people always want to support only their use-case and break other use-cases when there are compromises that can support both (given minor inconveniences to both).

> Which compromise are you proposing? Adding special casing in https://github.com/conda-forge/conda-smithy/pull/1865#issuecomment-2018182761 and use `conda_smithy.validate_schema.validate_json_schema` as the source of truth about hard vs soft errors in downstream code.

In light of https://github.com/conda-forge/conda-smithy/issues/1893 please update your answer. If you have a use-case other than the bot, please say so. Otherwise please don't break my workflows. I certainly don't understand...

Now that there are builtin cuda kernel support, it should be easy to write a memfill kernel and plug it to `pocl_cuda_submit_memfill`