[[!meta title="Iteration planning: November 05 – November 19"]] [[!meta date="2022-10-22 15:30:00 +0000"]] [[!tag meeting]] [[!toc levels=2]] # Extraordinary agendum - Heiko - Regarding [[!subplotissue 20]] (There's no way to specify a scenario only needs to run conditionally) - We referenced [[!sublotissue 228]] (Does not support labelling of scenarios) - We also spoke about the `USING` syntax from [Lars and Daniel's conversations in 2017](https://blog.digital-scurf.org/posts/yarn-architecture/) We discussed the fact that Heiko wishes to run tests which might cause the user problems if they run them in the wrong setup. Daniel suggested that there are a number of different ways we might look to meet Heiko's goal which is to ensure that users do not _accidentally_ run the 'delete all my files' scenario unless they really meant to. One option which Daniel suggested was to create a separate template which generates a `main()` function rather than relying on the `#[test]` attribute. This would be the simplest piece to implement; but it would require that all the bindings were taught about this new template in order to make it work. Another option Daniel suggested was to add some kind of configuration optionality to Subplot templates which would permit the templates to switch functionality on and off based on those configuration values. We'd probably want those to be specified up-front in the `template.yaml` but then perhaps we could envision something along the lines of `subplot codegen -o examples/dangerous.rs -t rust -C mode=standalone dangerous.subplot` or even allowing `dangerous.subplot` to specify configuration values in the `impls` block. Lars then discussed a little about how unit/integraion/system tests relate to one another, and explained a little about how Subplot's Rust scenarios might run in parallel whereas the Python runner executes serially always due to Python being unpleasant for us to implement parallelism here. We then discussed environment management and situations in which it's a good idea for subplot scenarios to manage resources (e.g. starting a server independently for each scenario) vs. having resources managed externally (e.g. starting a server before running `cargo test` and then tearing it down later). We had a non-subplot chat about virtual cards and the pain they produce. ## Outcome (ie. our work goals for now) We believe that the alternative-output mode for templates is the most desirable approach. We'd want both standalone vs. libtest and parallel vs. serialised. Lars asked if we could temporarily solve Heiko's problem with Python, but Heiko wisely decided that adding Python to his codebase would make everyone sad. Actions are documented at the end of this post. # Actions from last time - **DONE:** Lars to add to decisions document to lower threshold for making refactoring to improve code quality - **PARTIALLY DONE:** Lars to look at what it would take to use the `pulldown_cmark` parser for Markdown, instead of Pandoc, and make a concrete proposal of how to approach that. - proposal is not written down, but in summary: we'll use the Markdown parsing from Lars's ikiwiki clone, which gives us an AST modeled after HTML, and this will let us not use Pandoc for parsing at all - later on, we may choose to generate HTML ourselves, and drop direct support for generating PDF, and thus be able to drop the need for Pandoc at all; however, this is speculative - **STILL NOT DONE:** Daniel to open an issue with Cargo to discuss binary-only dependencies. # Assessment of the iteration that has ended We had chosen the following issues for this iteration: - **DONE:** [[!containerissue 4]] -- _Container is based on debian:buster - use bullseye instead?_ - **DONE:** [[!containerissue 5]] -- _Dockerfile could maybe be simplified_ - **NOT DONE:** [[!webissue 4]] -- _Review FAQ_ - **DONE:** [[!subplotissue 239]] -- _In metadata, `author` is a single string_ - **DONE:** (double-checked done) [[!subplotissue 281]] -- _Parsing markdown with Pandoc doesn't handle basedir_ # Discussion ## The gitlab.com hosting situation We reviewed [the billing page](https://gitlab.com/groups/subplot/-/billings) for Subplot on gitlab.com. It all looks OK. We're over the limit on seats, but it seems we can increase the seats for free. We will review the billing page every iteration or two. ## Repository review We reviewed issues updated since the previous meeting, merge requests, and CI pipelines for all the projects in the [Subplot group](https://gitlab.com/subplot) on gitlab.com. ### [Subplot Container Images](https://gitlab.com/subplot/subplot-container-images) - Open issues: 1 - Merge requests: 0 - Additional branches: 0 - CI: OK, ran Saturday morning ### [subplot-web](https://gitlab.com/subplot/subplot-web) - Open issues: 1 - Merge requests: 0 - Additional branches: 0 - CI: Ick, OK. ### [subplot](https://gitlab.com/subplot/subplot) - Open issues: 46 - Merge requests: 0 - Additional branches: - `docgen-cmark`, Lars is keeping this around for reference for future changes - CI: OK ## Recurring items issues There are some issues tagged [`recurring-agenda-item`](https://gitlab.com/groups/subplot/-/issues/?sort=created_asc&state=opened&label_name%5B%5D=recurring-agenda-item&first_page_size=20) in the issue tracker, which we discuss in every iteration meeting. - [[!subplotissue 119]] -- _Subplot is in not in Debian unstable_ - we will work on reducing Subplot dependencies that aren't already in Debian - need the dependency list; we are not targeting bookworm # Goals ## Goal 3: Current goal Subplot is altered to treat a YAML document as the root of any subplot document, permitting multiple markdown files to be joined into a single scenario set or output document. We remove our dependency on Pandoc’s AST for internal document representation, and support a better range of document metadata as a result. We will use marked data types where possible to permit better provenance information in error and warning messages; and we will strive to reenable the reference tests such that we can make a statement to the effect that post goal 3, we do not intend to make further breaking changes to the input formats or primary behaviours of Subplot. ([Related issues on gitlab](https://gitlab.com/subplot/subplot/-/issues?label_name%5B%5D=goal%3A%3A3)) ## Goal 4: Planned This goal is very likely to change. This is merely an initial sketch. We'll improve documentation and generally aim at making Subplot more plausibly usable by people outside of the Subplot project. ([Related issues on gitlab](https://gitlab.com/subplot/subplot/-/issues?label_name%5B%5D=goal%3A%3A4)) # Plan for new iteration ## Issues We spoke about: - [[!subplotissue 291]] (Could do with a user guide or Subplot book) Daniel pointed out that we _need_ to start having somewhere to put some content into place. We agreed that the primary rendering should be HTML. We chose to use `subplot docgen` as the initial rendering engine. We chose for Ick to render things into `doc.subplot.tech` for now. Lars will set up build etc. for this - [[!subplotissue 305]] (Maybe create binary releases?) Lars is going to have a go at doing this. - [[!subplotissue 308]] (Allow continuing commands across linebreaks) We labelled this goal 3, active-discussion, and added some notes around choosing mail-style for now. - [[!subplotissue 309]] (Lars needs a Subplot release) We agreed to do a release, Daniel will set it up. This will be 0.6.0 We intend to work on the following issues ([[!ms 7]]): - [[!webissue 4]] -- _Review FAQ_ - [[!subplotissue 309]] -- _Lars needs a Subplot release_ - [[!subplotissue 291]] -- _User guide/book_ - [[!subplotissue 305]] -- _Maybe create binary releases?_ ## Actions These are in addition to work on issues chosen for this iteration. - Daniel to write up an issue describing configurable templates, how they would look from the user perspective, and from an implementation perspective. Then to request feedback from Heiko. - Once that's done, Daniel or Lars to write standalone mode for Rust template. # Meeting participants - Daniel Silverstone - Lars Wirzenius - Heiko