Acceptance criteria to me: 1) Sufficient functionality to describe at least one example, of sufficient message complexity to indicate that other similar "real" examples should be possible
2) contains built-in tests for one or several such examples, showing each supported aspect working. 3) the tests are fully integrated - they run every time 'sbt test' is run on daffodil. 4) setup instructions for developers are there so that people know how to insure the required C tool-chain elements are there. These need to work on Linux and Windows. I believe these things insure that people working on other aspects of Daffodil will not be inadvertently breaking the C backend indetectably. That's one major concern I would have. ________________________________ From: Interrante, John A (GE Research, US) <[email protected]> Sent: Wednesday, March 10, 2021 4:24 PM To: [email protected] <[email protected]> Subject: Acceptance criteria for merging DFDL-to-C backend (runtime2-2202)? Thanks to Mike's suggestion, I have moved the Runtime2 ToDos (changes requested by reviewers) from the DAFFODIL-2202<https://issues.apache.org/jira/browse/DAFFODIL-2202> issue to an AsciiDoc document in the dev/design-notes subtree of the Daffodil website which you can read here: https://daffodil.apache.org/dev/design-notes/runtime2-todos/ I would like to discuss which acceptance criteria the runtime2-2202 development branch must meet before I can submit a pull request to merge the DFDL-to-C backend and code generator into the main branch. I plan to address the Runtime2 ToDos and I especially want to run some of Daffodil's TDML tests on the new runtime2 backend as well as the runtime1 backend by adding defaultImplementations="daffodil daffodil-runtime2" to certain TDML tests' attributes. (Although I suggest we use the shorter name "daf-c" or "runtime2" because "daffodil daffodil-runtime2" is a lot of characters to put into the defaultImplementations attribute.) Daffodil's Confluence describes Runtime2's design here: https://cwiki.apache.org/confluence/display/DAFFODIL/WIP:+Daffodil+Runtime+2 In particular, it suggests we divide the implementation of runtime2 into two distinct phases: * Phase 1 (aka Runtime2P1): No expressions. All lengths are fixed. All arrays have fixed length. * Phase 2 (aka Runtime2P2): Adding the DFDL expression language, lengthKind 'explicit', occursCountKind 'expression'. I think phase 1 is almost done but we need to run a subset of Daffodil's TDML tests on runtime2 before we can really say for sure. Here is an initial set of discussion points - more questions and criteria are welcome: 1. Which Daffodil TDML tests do we need to run on runtime2 to assert that phase 1 is complete? 2. Can we merge runtime2 when these tests pass and then build out phase 2 in the main branch, hopefully with help from other developers once they see how useful phase 1 is? 3. Which of the Runtime2 ToDos need to be done before the merge as well? Once we agree on a minimal set of acceptance criteria for the merge, I'll copy the criteria to the JIRA issue.
