Merge branch 'meeting' into 'main'

add draft meeting minutes for new planning meeting

See merge request obnam/obnam.org!64

1 files changed, 134 insertions, 0 deletions

diff --git a/blog/2021/12/06/planning.mdwn b/blog/2021/12/06/planning.mdwn
new file mode 100644
index 0000000..0e32615
--- /dev/null
+++ b/blog/2021/12/06/planning.mdwn
@@ -0,0 +1,134 @@
+[[!meta title="Iteration planning: December 6–20"]]
+[[!meta date="Mon, 06 Dec 2021 10:19:29 +0200"]]
+[[!tag meeting]]
+
+[[!toc levels=2]]
+
+# Assessment of the iteration that has ended
+
+[previous iteration]: /blog/2021/11/21/planning
+
+The goal of the [previous iteration][] was:
+
+> The goal of this iteration is to get a better picture of where the
+> performance bottlenecks currently are.
+
+This was completed. We added a new benchmark script. We also made
+release 0.6.0.
+
+# Discussion
+
+## Policy for `cargo deny`
+
+The discussion on how to tighten up the policy for `cargo deny` needs
+more input in [[!issue 157]].
+
+## Plans for Debian bookworm
+
+The Debian project has a release cadence of about two years. The next
+release is expected in mid-2023. Usually, the last six months or so
+development is gradually frozen, meaning new packages and package
+versions have a rising threshold to get in.
+
+That means that if we want Obnam to get into the next Debian major
+release, Debian 12, code named bookworm, we have a year to get it
+ready. The question is, then, what do we want to aim for? What is
+realistic for us to achieve in the year? What is the least that would
+be meaningful to include in a Debian stable release, and be supported
+by us for at least the next three years, without significant changes?
+Is there any point in even trying? Maybe we'd be better off staying
+out of bookworm?
+
+[[!issue 162]] has started collecting thoughts about this.
+
+## Benchmarks, benchmarks, benchmarks
+
+Lars feels he's flailing around, when it comes to making Obnam more
+performant, despite writing a couple of shell scripts to run
+benchmarks. Shell scripts are rarely a satisfactory solution. They're
+also too much work to run conveniently.
+
+Lars intends to write a program for Obnam benchmarks. This is covered
+in [[!issue 166]], but hasn't been planned in detail. Lars intends to
+produce a first prototype version as a base for further discussion of
+how benchmarks should be done.
+
+There will be a need do some analysis of the resulting measurement
+data. Lars has no idea about that. Help will be most welcome.
+
+## Splitting off the server part of the `obnam` crate?
+
+Would it make sense to split the Obnam server into its own crate? The
+code base is not yet very large, so that's not a sufficient
+justification. However, keeping them separate would enforce a stronger
+hygiene so that the client and server only ever communicate over a
+strict protocol, and do not even accidentally depend on each others'
+code.
+
+[[!issue 171]] collects opinions.
+
+
+
+# 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 for this iteration is to write a dedicated program for
+running benchmarks for Obnam.
+
+# Commitments for this iteration
+
+We collect issues for this iteration in [[!milestone 12]].
+
+Lars is not liking the winter darkness and wants to spend some time in
+deep hack mode for a bit, and a bit less time in planning mode. Thus
+he intends to hack up a prototype benchmark program in a
+stream-of-consciousness mode. It will be done in a separate
+repository.
+
+In addition, Lars intends to work on:
+
+- [[!issue 148]] _Doesn't check that backup being restored was made
+  with a compantible version of Obnam_
+  - the sooner we do this, the sooner we can safely start making
+    backwards incompatible changes (not that we necessarily have plans
+    for such right now, but just in case)
+  - 1h
+- [[!issue 151]] _Doc comments need review_
+  - this is better done as we go along, rather than leaving it into a
+    big lump of a chore close to a production release
+  - 4h
+- [[!issue 167]] _Release process should tell you to update Cargo.lock
+  after updating crate version number_
+  - not doing this breaks building of the Obnam .deb package in Lars's
+    personal CI, so it's an annoyance, but quick to fix
+  - 0.25h
+- [[!issue 172]] _Release version 0.7.0_
+  - make frequent releases to get used to making frequent releases
+  - 1h
+
+# Meeting participants
+
+* Lars Wirzenius