Review of actions from previous meeting

Actions from last time, and their status are:

  • Lars will open an issue to use pandoc-filter-diagram. DONE Subplot issue 260

  • Lars will approach WMF about how scap uses Subplot. Lars spoke to Brennan and they are still using it. They’ve not changed how they use it, so Lars knows it all still.

  • We submitted a talk proposal to the Safety in Open Source devroom.

Review of the iteration that has ended

Subplot milestone 41 was long, and we did not complete anything. That’s OK.

We made some progress on:

We moved some of the open issues to the next milestone (Subplot milestone 42) and then closed off this iteration having unmilestoned everything else.

Review of the repositories

Currently open MRs:

  • subplot: one draft, solving Subplot issue 259
  • subplot-web: none
  • subplot-container-images: none

Extra branches unrelated to MRs:

  • subplot:
    • subplot-rust – Daniel is keeping this around until he has completed the work on Subplot issue 141.
    • docgen-cmark – Lars is working on making docgen use cmark rather than pandoc for the initial parse and processing.
    • more-rust-subplots – Daniel is working here to solve Subplot issue 259
  • subplot-web: none
  • subplot-container-images: none


  • subplot: clean
  • subplot-web: none
  • subplot-container-images: clean, and we triggered the one to build a new container image

Current goal (goal 2; not changed for this iteration)

Subplot provides a set of libraries with identical capabilities in each of the supported languages. Python remains a supported language. Rust is promoted to supported-language status. Subplot will be tested with all supported languages. In addition, any quality of life improvements which can be done shall be done. This goal will be considered complete when a release of Subplot has been made with the unified language handling support complete.

Issue review

We had 56 open issues at the start of the meeting.

We reviewed non-someday-maybe issues for subplot that have been changed since thee previous meeting.

We made the following changes:

  • Subplot issue 261 Cleanup functions should run regardless… we discussed, agreed, retitiled, and labelled this - we want it doing, but we’re not in a rush to get it done.
  • Subplot issue 262 Should subplotlib ScenarioContext derive Debug? we discussed, agreed, retitled, and labelled this for further discussion.
  • Subplot issue 263 What is a good way to include Rust… we discussed, labelled, and put this aside for now. We should return to this one once we’ve finished our talk.
  • Subplot issue 264 The Subplot subplot should verify we support all the Markdown features we want to support We discussed this, and labelled it someday-maybe and docgen

We left the docker-for-subplot issue alone, and subplot-web had no issues.

Plan for next iteration

We opened Subplot milestone 42 to cover this iteration, with the following issues:

Wew assigned the dependency issues to Lars.

Other business

Lars provided his gripes from his attempt to use Subplot’s Rust template when writing a test suite for his Obnam benchmarking tool:

  • Gripes I have about Subplot with Rust template.

    • overall, Rust step functions are too much magic

      • great when everything works, not when something doesn’t
    • it’s too damn hard to debug a failure when a step function fails

      • which step failed?
      • runcmd eats stdout and stderr
      • not just about logging
    • the way we use macros to implement step functions is harmful

      • at runtime (“cargo test”), line numbers are useless: last line of step function
      • they confuse compiler: Result values can be ignored, which can lead to bugs
    • codegen as a separate step meshes badly with Rust tooling

    • is unergonomic - systemic with Rust, not specific to Subplot

      • when there’s a problem, it’s unnecessarily hard to find the source file
    • having source files for step functions not be part of the crate means tooling like “cargo fmt” doesn’t find it

  • We decided to defer making a release of whatever is in the main branch until we have done our talk. When we do, we’ll label it 0.3.2 or 0.4.0, depending on whether it has breaking changes or not. Subplot issue 254

  • We are not yet ready to file an RFP bug to get Subplot packaged for Debian. It will happen after we think we won’t be making breaking changes anymore. We probably want to do a review of the dependencies as well, to make packaging easier.

  • We are not yet ready to make a whole code base review of Subplot. However we feel at least part of the new goal 3 will be reviewing a portion of the code.

  • We will switch an issue based agenda when other people join the meeting.

  • We won’t be reaching out for feedback until goal 3 is done.

  • Regarding talk preparation:

    1. We have submitted to the Safety in Open Source devroom
    2. We need to prepare an outline etc.
    3. Daniel will write an outline, provide it to Lars to review, and then we can write the content during the iteration.
  • Regarding the media repository question - we believe this is premature at this point - once we are ready to write the talk mentioned above, it will be time for the repository.

  • Lars spotted during the holiday period and raised the question “Should we stop using the term ‘stakeholder’ in Subplot?” - we discussed this briefly and concluded that if there was a better term, we would happily switch, but in the absence of such, we do not feel that ‘stakeholder’ is inherently bad and so will not choose to switch to a less useful term by default.


  • Daniel will review Lars’ gripes and look to file appropriate issues to cover correcting the problems

  • Between Daniel and Lars - the talk will be drafted.