Assessment of the iteration that has ended

The goal of the previous iteration was:

The goal for this iteration is to further improve our ability to make changes to Obnam safely.

What an non-specific goal. In any case, it was achieved: that's the nice part of not being specific. Lars changed Obnam to allow it to migrate to another checksum algorithm for chunks and de-duplication without breaking existing users. This is obnam#203, and done in !228, not yet merged.

Discussion

Current development theme

The current theme of development for Obnam is convenience. The choices are performance, security, convenience, and tidy-up, at least currently.

Repository review

Lars reviewed all the open issues, merge requests, and CI pipelines for all the projects in the Obnam group on gitlab.com.

Container Images

• Open issues: 0
• Merge requests: 0
• Additional branches: 0
• CI: OK, ran on Monday, April 11

obnam.org

• Open issues: 0
• Merge requests: 0
• Additional branches: 0
• CI: not defined

obnam-benchmark

• Open issues: 11
• Merge requests: 0
• Additional branches: 0
• CI: not defined

cachedir

• Open issues: 0
• Merge requests: 0
• Additional branches: 0
• CI: not defined

summain

• Open issues: 0
• Merge requests: 0
• Additional branches: 0
• CI: not defined

obnam

• Open issues: 54
• Merge requests: 1
  • !228 - add support for migrating to new checksum types
    • to be merged on Tuesday
• Additional branches: 1
  • perf-stats -- obsolete, deleted during meeting
• CI: OK

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 easier and safer to change, both for developers and end users. This means that developers need to be able to make breaking changes without users having to suffer. User shall be able to migrate their data, when they feel it worthwhile, not just because there is a new version.

Goal for this iteration (new for this iteration)

The goal of this iteration is to prepare for future changes: document threats against the chunk server API (so that authentication can be added in the future), and making an client-internal abstraction for using the chunk store (so that it can later be local as well as remote).

Commitments for this iteration

Lars intends to work on the following issues:

• obnam#29 -- Doesn't provide information on SQLite file sizes
  • Lars will add that functionality to the Obnam client
  • 1h
• obnam#188 -- May store large unsigned numbers incorrectly in SQLite?
  • Lars will add a test to verify that the biggest 64-bit number can be stored in SQLite and correctly retrieved back.
  • 1h
• obnam#190 -- obnam.md doesn't explain why we back up CACHEDIR.TAG files
  • Lars will amend the documentation in the subplot
  • 0.25h
• obnam#206 -- Lacks a release with recent changes
  • Lars will make a release and run benchmarks.
  • 1h
• obnam#207 -- What threats would a server API authentication defend against?
  • Lars to add an initial threat model for server API. This needs to be done before it's sensible to discuss how authentication would be implemented.
  • 1h
• obnam#208 -- Needs internal interface for using chunk storage
  • Lars to add an internal interface and implement it for a remote chunk store.
  • 4h

Meeting participants

• Lars Wirzenius