docs: add minutes for new planning meeting

1 files changed, 165 insertions, 0 deletions

diff --git a/blog/2021/04/18/meeting.mdwn b/blog/2021/04/18/meeting.mdwn
new file mode 100644
index 0000000..6ee4f8c
--- /dev/null
+++ b/blog/2021/04/18/meeting.mdwn
@@ -0,0 +1,165 @@
+[[!meta title="Iteration planning: April 18—April 25"]]
+[[!tag meeting]]
+
+[[!toc levels=1]]
+
+# Assessment of the iteration that has ended
+
+[previous iteration]: /blog/2021/03/28/planning
+
+The goal for the [previous iteration][] was:
+
+> The goal for this iteration is to implement a reasonable `obnam init`,
+> which reads a passphrase from the user, and derives two keys from it,
+> and stores them into `~/.config/obnam/secrets.yaml`, with file-system
+> permissions of 0400 (or `-r------` in ls notation). It is not part of
+> the goal to actually use those keys in any way.
+
+That goal was reached.
+
+Unfortunately, Lars was busy with life and things and did not have
+time to prepare a new iteration. Thus, there was an week between the
+iteration ending and the next iteration.
+
+# Discussion
+
+## The new `init` subcommand
+
+The `obnam init` functionality is probably too simplistic for most use
+cases that care about security. That's OK, it's a step towards
+something good.  Issue [[!issue 104]] collects ideas for how to do
+that well. For a good long time, the current way will do, and lets us
+start work on actually encrypting data and verifying the data is
+intact when downloading it.
+
+## Code review
+
+One thing that Lars noticed while doing the init work is that after
+creating the merge request, he immediately merged it himself. There
+was no code review. In fact, that is basically what happens with every
+change to Obnam. On the one hand, this is natural, as Lars is
+currently the only one working on the code; this also allows Lars to
+move quickly, which is important for keeping his motivation up. On the
+other hand, it's a self-sustaining situation, since nobody else
+currently even has a chance to review, since the time between pushing
+a change to the git server and it getting merged tends to be on the
+order of seconds. Something needs to change about the process.
+
+Lars is thus proposing a change to how Obnam code review will work:
+
+* Lars will push changes, and for each change set a value for N, which
+  may be different for each change.
+* Lars will wait for N days for comments, and if nothing has been
+  raised that would prevent a merge, and if discussion isn't
+  continuing, Lars will merge.
+* Comments on merge requests on gitlab.com will be open: anyone will
+  be able to comment.
+* Lars may update the MR based on feedback, applying his best
+  judgment.
+  
+Typical values for N will be:
+
+* 0 for typo fixes and similar low-impact changes, or fixes to
+  urgent high-impact issues
+* 1 for other urgent changes
+* 3 for most changes – this will be the default
+* 5 for changes likely to be controversial or affecting security
+  related code
+
+Lars will advertise the merge requests via various channels. The hope
+is that this will eventually attract people to do reviews. As time
+goes by, and trust is built, some of those people will get the
+"approve" or "merge" privilege. The "approve" privilege allows marking
+a merge request as "approved", allowing someone else to merge. The
+"merge" one will allow telling GitLab to actually merge the change,
+closing the merge request.
+
+Merge requests by others will follow the same process.
+
+This workflow should at least open the door to code review without
+slowing down development too much.
+
+## Iteration length
+
+Obnam has been using two-week iterations so far. However, this turns
+out to be quite a long time, and many things happen in two weeks,
+internally and externally. It's also such a long time that there's
+either a tendency to take on too much work for the iteration and not
+being able to do it all, or doing other things for most of the
+iteration and then cram right before the iteration ends. Neither is
+good.
+
+Lars thus proposes that Obnam will experiment with one-week
+iterations. Since Lars is the only one who currently has any
+decision-making power, the motion carries with extraordinary
+unanimity.
+
+## Governance
+
+When the project starts having other regular contributors, some form
+of formal governance will be needed. But it's too early to decide on
+that. Lars tends to prefer democracy and voting.
+
+
+# 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 support encryption
+well. This will involve having a documented threat model, which has
+been reviewed by all stakeholders participating in the project, and
+Obnam defending against all the modeled threats.
+
+## Goal for the iteration that is starting
+
+FIXME: actually write this; some ideas:
+
+- do rudimentary AEAD on chunks
+- learn about async and prepare an initial plan for using it in the
+  client
+
+# Commitments for this iteration
+
+FIXME: This all needs to be thought out and tasks selected carefully.
+This is all a very rough collection of ideas for now.
+
+[[!milestone 8]] represents this iteration on GitLab.
+
+For this iteration, Lars is committed to resolving the following
+issues:
+
+- [[!issue 28]] - large vectors
+- [[!issue 34]] - timestamps to order genreations
+- [[!issue 50]] - repo integrity check
+- [[!issue 56]] - metadata about databases in the databases
+- [[!issue 62]] - document chunk relationships
+- [[!issue 70]] - warnings at end
+- [[!issue 81]] - cleanup of temp file for db in panic
+- [[!issue 88]] - symlinks
+- [[!issue 102]] - tilde expansion in config file
+- [[!issue 106]] - client log file rotation
+- [[!issue 108]] - unhelpful error messages
+- make release (needs an issue)
+- learn about async Rust (needs an issue?)
+
+That is a total of about FIXME hours, rough estimate.
+
+# Meeting participants
+
+* Lars Wirzenius