| [jts-dev] Guidance on packaging small robustness / ownership fixes for upstream JTS |
Hello, Following the JTS contribution guidance, I am asking here before opening further pull requests. This came up while discussing corresponding changes in the NetTopologySuite port, where I was asked to establish the changes in upstream JTS first. I have two kinds of possible contribution: 1. Coordinate ownership / aliasing BufferInputLineSimplifier and OverlayNG.Edge appear to retain caller-supplied coordinate objects across an operation boundary. I have small candidate changes using CoordinateArrays.copyDeep so that caller-owned and operation-owned coordinates do not remain aliased. I would submit each change with a minimal regression test that demonstrates the ownership problem independently. Would you prefer one issue and pull request per class, or one narrowly scoped ownership change covering both classes? 2. Algorithmic robustness work Separately, I have possible contributions involving orientation filters, hybrid predicates, and curve-related numerical residuals. I would not combine those into one pull request. For work of that kind, would you prefer one focused issue per predicate or algorithm, containing the motivating case, proposed approach, tests, and relevant performance data, before any code is submitted? I would present proposed changes in ordinary JTS terms: a concrete failure or invariant, a minimal patch, regression tests, and any relevant performance impact. Formal proofs and larger research artifacts can remain in a separate repository and be linked only as optional supporting evidence. A short indication of the preferred starting point and review grain would be enough to guide the next submission. Jeroen Bloemscheer https://github.com/grootstebozewolf jeroen.bloemscheer@xxxxxxxxxxxx |