nssalian commented on PR #4: URL: https://github.com/apache/iceberg-verification/pull/4#issuecomment-5589428247
Thanks for taking a look @sungwy. I put this up to help start the conversation. I think hybrid shape is right - we shouldn't stand up a runner for every surface. But I'd split by what the assertion needs, not by pre-merge vs post-merge. Where the answer is spec-derivable with no implementation-specific knowledge, the central runner is cheap and, more to the point, needs zero buy-in from an implementation to produce a signal - an impl that never wires up a submodule still gets checked. Types is the clear case: it comes straight out of the Primitive Types table and Appendix C, so I'd keep it here as a standalone surface. Where the assertion genuinely needs impl internals (manifests, deletion vectors, snapshot lineage), I agree the impl should own the check and the submodule/pin path is the right home. Two things I'd push on before leaning hard on the submodule model for the low-level surfaces. - First, the pre-merge visibility is real but contingent: it only exists for impls that adopt the submodule and keep the pin current, and the central runner is what covers everyone who hasn't. - Second, if an implementation owns both the code under test and the adapter that projects its object into the fixture shape, a shared misreading can conform to the fixture and hide a divergence - which is the failure this repo exists to catch. The answer key stays single-sourced either way; I just want adapter ownership to be a deliberate call. I've left similar comments in response to the others To make the subscribe path concrete, the next revision I plan to put in adds a surfaces manifest, a `--surface` filter on the runners so a consumer runs only what it opts into, and a CONTRIBUTING recipe for the submodule/pin flow. Net split: runners for spec-derivable/cross-cutting surfaces, submodule for anything that needs impl internals - which keeps types central. Let me know if that boundary sounds right to you? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
