blob: cfc478049f393aab908a8e6313bf61210a7b3d44 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
|
[[!meta title="Iteration planning note: July 18"]]
[[!tag meeting]]
[[!meta date="2020-07-18 18:00"]]
# What has happened?
We completed [[!issue 68]] and [[!issue 12]]. [[!issue 20]] remains incomplete
at this time.
Lars has started to deal with the fallout of renaming the default branch to
be `main` in his ick configuration.
We've agreed to dogfood this for a while in case something breaks, and think
about what we might change otherwise (e.g. the website repo) in the future.
We agreed we were OK with all this and so closed [[!milestone 10]].
# Issue review
We reviewed the situation for all the open issues, for the most part nothing
was changed, however the following tweaks were done:
* Lars was reading an article about abstraction and coupling between modules,
which was of the opinion that inter-crate APIs are cleaner. Cargo enforces
a DAG on crates. He created [[!issue 53]] a while ago and has updated that
issue with a note on this.
- After some discussion, we decided to create [[!issue 69]] to cover the
splitting up of `ast.rs` and the factoring out of tests into independent
files.
* We linked [[!issue 27]] and [[!issue 36]] because they're both related to
styling.
* We determined that [[!issue 37]] was completed anyway and so closed it
We agreed to continue with our current issue-filing and closing/keeping flow
the same for now.
# Milestone planning
New iteration is [[!milestone 11]]
Contains:
* [[!issue 20]] - Carried and still assigned to Daniel
* [[!issue 69]] - Assigned to Lars
* [[!issue 62]] - Assigned to Lars to drive discussion and writing of docs
# Debugging test programs
Lars started to change `ewww` so it would actually serve files. This involved
learning new things about `warp` which weren't too bad; but while learning them,
problems were encountered because initial guesses on how to work with it were wrong
and Lars had a devil of a time debugging the generated test program which was failing.
The fundamental problem was that each scenario got a generated directory and since
that consumes disk space it deletes them after the program ends. This is fine
when the scenario passes but makes it harder to debug on failure. This is a
problem common to other tools such as `yarn`.
We should attempt to make this experience as smooth as possible because it's
not going to be unusual for people to need to diagnose test failures.
Daniel suggested adding 'keep on failure' or 'shell on failure' type approaches.
Lars had spoken to a friend who suggested:
1. 'on failure, make a data tarball/copy/whatever'.
2. 'on failure, open a shell prompt'
3. 'on failure, snapshot a container/vm/whatever'
We decided that Lars will write a story about a successful debugging experience
with tooling which did all the right things, and from there we can derive
some initial requirements for subplot's built-in runner templates.
|
