On 15/10/2024 20:44, Rob Herring wrote:
On Tue, Oct 15, 2024 at 02:28:06PM +0300, Laurent Pinchart wrote:
Hi Krzysztof,
On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote:
On 14/10/2024 22:29, Laurent Pinchart wrote:
On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote:
On 14/10/2024 10:31, Bryan O'Donoghue wrote:
On 14/10/2024 08:45, Krzysztof Kozlowski wrote:
I do not understand the reasoning behind this change at all. I don't
think DT maintainers ever suggested it (in fact, rather opposite:
suggested using unevaluatedProps) and I think is not a consensus of any
talks.
No there is not but then, how do you give consistent feedback except
proposing something to be a baseline.
On the one hand you have upstream additionalProperties: false and
unevaluatedProperites: false - it'd be better to have a consistent
message on which is to be used.
There are 3 options:
- no $ref => additionalProperties
I interpret this to mean that omitting
additionalProperties/unevaluatedProperties is logically the same as
having additionalProperties as you will then need to list the properties
explicitly.
- has a $ref:
- additionalProperties and list ref-ed properties
- unevaluatedProperties and don't list ref-ed properties
I do debate (with myself) that that is too complicated as many don't
understand the difference.
We could go back to always using
additionalProperties which is what we had before unevaluatedProperties
was added. The other option is always use unevaluatedProperties. 2
things have stopped me from going that route. I don't care to fix
'additionalProperties' treewide which would be necessary to implement a
meta-schema or check that unevaluatedProperties is used. It's not
something I want to manually check in reviews. The other reason is just
to not change what the rules are again.
Right so I received feedback to change link-frequencies if I recall. I
thought I had been very-clever (tm) by copying an upstream source and
when I received feedback to change assumed the upstream source I had
copied had bit-rot w/r/t the current preferred way.
Some additional discussion shows there really isn't a preferred way at
present.
Is there a place to meaningfully document that conclusion instead both
for reviewers and implementers ?
Should I already know the answer to that question ?
---
bod
