1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
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
|
