meeting: add draft meeting minutes for new iteration planning

Sponsored-by: author

1 files changed, 106 insertions, 0 deletions

diff --git a/blog/2021/09/12/planning.mdwn b/blog/2021/09/12/planning.mdwn
new file mode 100644
index 0000000..b5256cd
--- /dev/null
+++ b/blog/2021/09/12/planning.mdwn
@@ -0,0 +1,106 @@
+[[!meta title="Iteration planning: September 12—September 26"]]
+[[!tag meeting]]
+
+[[!toc levels=2]]
+
+# Assessment of the iteration that has ended
+
+[previous iteration]: /blog/2021/08/29/planning
+
+The goal of the [previous iteration][] was:
+
+> Finish the work to change the Obnam client to use async Rust for
+> making backups. Once this works and is merged, make a new release.
+
+This was not entirely achieved: a release was not made. The release
+will be carried over to the new iteration.
+
+# Discussion
+
+## Development themes
+
+Lars has thinking further on how to structure Obnam development and is
+now thinking that it needs to rotate between three themes:
+convenience, performance, and security. Each iteration, or short
+sequence of iterations, should pick one of the themes, and
+concentrate on that. All three are important for Obnam, so all three
+should get attention, but splitting the attention tends to result in a
+more chaotic development process.
+
+## Licensing
+
+In [[!issue 122]], Alexander asks why Obnam is under the GPLv3
+license, instead of AGPLv3. Lars is inclined to change the license,
+but doing so needs a check that no other contributors need to be
+asked.
+
+# Goals
+
+## Goal for 1.0 (not changed this iteration)
+
+The goal for version 1.0 is for Obnam to be an utterly boring backup
+solution for Linux command line users. It should just work, be
+performant, secure, and well-documented.
+
+It is not a goal for version 1.0 to have been ported to other
+operating systems, but if there are volunteers to do that, and to
+commit to supporting their port, ports will be welcome.
+
+Other user interfaces is likely to happen only after 1.0.
+
+The server component will support multiple clients in a way that
+doesn’t let them see each other’s data. It is not a goal for clients
+to be able to share data, even if the clients trust each other.
+
+## Goal for the next few iterations (not changed for this iteration)
+
+The goal for next few iterations is to have Obnam be performant. This
+will include, at least, making the client use more concurrency so that
+it can use more CPU cores to compute checksums for de-duplication.
+
+## Goal for this iteration (new for this iteration)
+
+The goal of this iteration is to set up a way to check what the
+performance of Obnam is, by implementing a simple benchmark, running
+that, and recording the results.
+
+
+# Commitments for this iteration
+
+Lars intends to set up an initial benchmark, and do some chores to
+tidy up things.
+
+* [[!issue 56]] -- SQLite databases for generations have no metadata
+  about themselves (1h)
+  - this is relevant for performance so that we can more safely make
+    changes for performance later
+* [[!issue 96]] -- Lacks benchmark of the initial backup a large file
+  (4h)
+  - this is the big task for this iteration, the start of doing
+    systematic benchmarks
+* [[!issue 122]] -- Why isn't Obnam licensed under AGPL? (0.25h)
+  - check who've made significant contributions so that we can change
+    the license later
+* [[!issue 127]] -- Merge policies are undocumented (1h)
+  - draft an update for `DONE.md` to add merge policies
+  - this will hopefully make it easier to handle future code
+    contributions
+* [[!issue 130]] -- Requires moreutils just for chronic (0.25h)
+  - this will reduce the build dependencies
+* [[!issue 131]] -- Benchmark code is in src/bin and doesn't seem to
+  work (1h)
+  - fix the benchmark code so it works
+  - move it to a better place or drop it entirely
+  - this tidies up the code base
+* [[!issue 136]] -- Doesn't have a type for checksums (0.25h)
+  - this will make it harder to mix checksum values with other strings
+* [[!issue 138]] -- Requirements in `obnam.md` haven't been reviewed
+  lately (0.25h)
+  - we should review requirements from time to time
+
+That's a total of about 8 hours, rough estimate, for Lars. This may be
+a little optimistic.
+
+# Meeting participants
+
+* Lars Wirzenius