Merge branch 'meeting' into 'main'

: add placeholder for planning meeting

See merge request obnam/obnam.org!46

1 files changed, 98 insertions, 0 deletions

diff --git a/blog/2021/07/04/meetings.mdwn b/blog/2021/07/04/meetings.mdwn
new file mode 100644
index 0000000..216010c
--- /dev/null
+++ b/blog/2021/07/04/meetings.mdwn
@@ -0,0 +1,98 @@
+[[!meta title="Iteration planning: July 4–18"]]
+[[!tag meeting]]
+
+[[!toc levels=1]]
+
+# Assessment of the iteration that has ended
+
+[previous iteration]: /blog/2021/06/06/meeting
+
+The goal of the [previous iteration][] was:
+
+> Change the Obnam client to use async Rust to be more concurrent. The
+> result doesn't need to make optimal use of all cores, but it needs
+> to pass the test suite and needs to work.
+
+This was not achieved, due to Lars being busy with changing jobs.
+Overall, not a lot of things happened this iteration. This is not a
+problem: Obnam is a hobby project, and is worked on when it's fun.
+Obnam is not intended to be "feature complete" as quickly as possible.
+It's meant to become a solid backup solution for the long term. Also,
+it's meant to be fun.
+
+# Discussion
+
+Lars has accepted a new job and has some time before it starts, and
+intends to do some work on Obnam. This iteration picks up where the
+previous iteration started.
+
+Lars has been doing some thinking about Obnam development strategy,
+and feels that there are several features that affect the software
+architecture deeply:
+
+* security and safety
+  - encryption of backed up data
+  - replay attacks
+  - handling of encryption keys
+  - other threats
+* performance
+  - concurrency in client
+  - caching of data chunks
+  - handling huge amounts of data
+  - handling huge numbers of files
+  - event-driven operation over scanning the file system
+* shared backup repository
+  - supporting many clients on the server
+  - sharing backed up data between clients
+
+Lars concludes that it doesn't really make sense to work on all of
+these at once. Instead, he will work on one aspect of one feature at a
+time, over one or a few iterations. Currently that's concurrency in
+the client.
+
+# 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 (same as last iteration)
+
+Change the Obnam client to use async Rust to be more concurrent. The
+result doesn't need to make optimal use of all cores, but it needs to
+pass the test suite and needs to work.
+
+
+# Commitments for this iteration
+
+Lars intends to make a proof-of-concept prototype for using async Rust
+in the client for chunking live data, and computing checksums for
+chunks, using all the computing resources available. This will be part
+of [[!issue 113]] (client is not async), but is too experimental to
+estimate at this time.
+
+In addition, Lars intends to work on [[!issue 111]] to document what
+Obnam's subplot needs.
+
+
+# Meeting participants
+
+* Lars Wirzenius