summaryrefslogtreecommitdiff
path: root/blog
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2021-02-28 20:09:06 +0200
committerLars Wirzenius <liw@liw.fi>2021-02-28 20:09:06 +0200
commit4815a6cb75bc48eabdb9765f91d76cb08f424563 (patch)
tree282156fa32d7ea5d1053b029f36043e83bed487a /blog
parentabb9c6cfc5faeaadb7f0aeb7f4cf4512aae18814 (diff)
downloadobnam.org-4815a6cb75bc48eabdb9765f91d76cb08f424563.tar.gz
feat: iteration planning meeting
Diffstat (limited to 'blog')
-rw-r--r--blog/2021/02/28/planning.mdwn110
1 files changed, 110 insertions, 0 deletions
diff --git a/blog/2021/02/28/planning.mdwn b/blog/2021/02/28/planning.mdwn
new file mode 100644
index 0000000..218ea25
--- /dev/null
+++ b/blog/2021/02/28/planning.mdwn
@@ -0,0 +1,110 @@
+[[!meta title="Iteration planning: February 28"]]
+[[!tag meeting]]
+[[!meta date="Sun, 28 Feb 2021 19:18:42 +0200"]]
+
+# Assessment of the iteration that is ending
+
+The goal for the [iteration that has just ended][] was:
+
+> By the end of this iteration, Obnam will have a plan for how to
+> implement encryption for the initial [threat model][] of the server
+> operator reading backed up data. This will cover the encryption
+> algorithm, how the encryption secret is handled, and Obnam can change
+> its encryption in the future.
+>
+> A new release will be made by the end of the iteration.
+
+That goal was not reached. There is a plan for implementing
+encryption, but it needs at least one more round of review.
+
+Also, no release was made. This time my excuse is that I need to
+re-invent my release automation so that making releases is less
+tedious. It's not a very convincing excuse.
+
+[iteration that has just ended]: /blog/2021/02/15/iteration
+[threat model]: https://doc.obnam.org/obnam.html#threat-model
+
+# Discussion
+
+There was some good, constructive feedback on the encryption plan.
+This was very pleasing, and motivational. There was other good
+feedback as well, and some private discussions, which will hopefully
+continue and move to the public soon.
+
+The discussion so far about encryption has highlighted that I am very
+much not an expert in this area. I will try to tread carefully.
+However, I'm also intentionally not going to aim for perfection on the
+first try. That doesn't ever happen. Perfection requires many
+iterations. Thus, I don't expect Obnam to be very secure in the next
+several iterations, but I do intend to make it better in each
+iteration.
+
+I've been trying Obnam out on some of my own, real data, specifically
+my 1.3 million personal email archive. It's painfully slow. I suspect
+some optimization work would be good, because otherwise I won't want
+to use the software myself.
+
+There are also a bunch of small issues piling up, "paper cuts", and I
+really should not let them pile up too much.
+
+
+# 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.
+
+## This iteration
+
+By the end of this iteration, I have merged the plan for implementing
+encryption. It is not necessary for the encryption to have been
+implemented. This is going to require learning new aspects of Rust,
+and new crates, and thus I expect that the actual implementation will
+take more than one iteration.
+
+I will also have implemented a benchmark for simulating the workload
+of my email backups, and I have measurements to show where time is
+being spent.
+
+I have made a new release.
+
+
+
+# Tasks for this iteration
+
+For this iteration, I'm committed to resolving the following issues:
+[[!issue 18]] (1h),
+[[!issue 36]] (1h),
+[[!issue 59]] (0.25h),
+[[!issue 62]] (0.25h),
+[[!issue 74]] (0.25h),
+[[!issue 79]] (0.25h),
+[[!issue 82]] (1h),
+[[!issue 83]] (1h),
+[[!issue 84]] (1h),
+[[!issue 87]] (1h)
+and
+[[!issue 96]] (1h).
+
+Total of about 8 hours, rough estimate.
+
+Created [[!milestone 6]] for this iteration.