TODO


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

* Documentation
  - More gtk-doc

* Local metadata packs
  - Just to avoid lots of little files on each client

* Hybrid SSL pull (fetch refs over SSL, content via plain HTTP)

* ostree-commit: multithreaded/async (basically compute sha256 in parallel)
  - Also speed up devino cache by having a big mmappable file that maps from
    (device, inode) -> checksum.  We need to keep the cache up to date;
    investigate something like http://www.sqlite.org/wal.html for having
    a shared file.

* https://bugzilla.gnome.org/show_bug.cgi?id=721799
  https://mail.gnome.org/archives/ostree-list/2013-July/msg00005.html
  Efficient delta format between commit objects, somewhat like
  Chromium autoupdate: set of operations to perform given previous
  object set to create new objects.

* Flexible "prune" that allows keeping only a rolling subset of history.
  For example, keep the last week, keep at least 1 build a week up
  till a year ago, then 1 build a month, etc.  Optionally rewrite commit
  parent history?

* Tests of corrupted repositories, more error conditions

* Structured output from commandline?  ostree --output={table,gvariant} ?

* Better output on a tty - progress bars
  Needs size metadata; see https://bugzilla.gnome.org/show_bug.cgi?id=709050
  https://bugzilla.gnome.org/show_bug.cgi?id=721799

* Do HTTP requests as unprivileged user (particularly before we've
  done GPG verification)
  https://bugzilla.gnome.org/show_bug.cgi?id=730037

* Reintroduce "ostree admin install": Could pull in host data,
  such as uids and /etc/fstab.

* Possibly move all of the "regular" commands to be "ostree repo" ?  Then
  we'd have: "ostree repo pull", "ostree repo ls", etc.

* Multiple backends (BTRFS, etc.)

* PackageKit backend