Assessment of the iteration that has ended

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.


Policy for cargo deny

The discussion on how to tighten up the policy for cargo deny needs more input in obnam#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?

obnam#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 obnam#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.

obnam#171 collects opinions.


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:

  • obnam#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
  • obnam#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
  • obnam#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
  • obnam#172 Release version 0.7.0
    • make frequent releases to get used to making frequent releases
    • 1h

Meeting participants

  • Lars Wirzenius