Remove ROADMAP. All of it has been moved to the bug tracker.

1 files changed, 0 insertions, 121 deletions

diff --git a/ROADMAP b/ROADMAP
deleted file mode 100644
index 789b6c18..00000000
--- a/ROADMAP
+++ /dev/null
@@ -1,121 +0,0 @@
-Roadmap for Obnam development
-=============================
-
-This is not really a roadmap, sorry. It does contain some plans
-for what will hopefully happen, but without dates attached. It also
-has notes for what might be good ideas to do some day in the future.
-
-
-Simply bugs, to be fixed
-------------------------
-
-* blackboxtest is ugly code, could do with some heavy refactoring
-  to clean it up. The goal is to make the code so simple and
-  straightforward it is clear that it works, and what each test
-  does.
-
-
-B-tree Store implementation
-----------------------------
-
-* Implement the functional B-trees the btrfs filesystem uses, and
-  then use them for a new implementation of the Store class.
-
-
-Sensible ideas
---------------
-  
-* Extended attributes and ACLs should be supported.
-  * acl(5), lsattr(1)
-  * python-acls
-  * python-xattrs
-
-* Write a plugin to do error correcting codes on data stored in
-  the backup store.
-
-* LocalFS should use posix_fadvise to avoid data being cached.
-  Data that just gets backed up probably does not need to be in the 
-  cache.
-
-* When we cache backup metadata locally, use the cachedir specification
-  to mark the cache directories. Also, add an option to avoid such
-  directories from being backed up.
-    - http://www.bford.info/cachedir/
-
-* Have SftpFS use ssh(1) when available, rather than just paramiko,
-  to speed things up. bzr does this.
-
-* Progress reporting should show transfer speeds, and estimate the
-  remaining time.
-
-* When backing up a file, see if it keeps changing and if so, do
-  something sensible about it. For example, log files, especially
-  obnam's own log file.
-
-* Should store the full resolution timestamp, not round it to a whole
-  second.
-  
-* It would be cool if obnam could measure its own performance, using
-  some lightweight measurements such as utimes, and report this at
-  the end of the run in the log file. This would make it easier to
-  notice when performance slides, or (if log files are kept), look
-  back in history to whenit started to slide.
-
-* Use my assert-licenses tool in "make check" to verify that all
-  files have the correct license.
-  
-* "obnam --help" should list all commands.
-
-* Virtual file system implementations should be moved into plugins.
-
-* Add option to verify that there is no hash collision when chunks
-  or chunk groups have the same hash.
-
-* Make verify be able to choose files to verify randomly.
-
-* Implement a --no-act (alias --dry-run) option which prevents obnam
-  from doing anything destructive (essentially: no writes). For
-  backups, it would do everything except write operations to the store
-  (including locking etc). For restore, everything except actually
-  writing out the files to the target directory. For forget, it would
-  just list what it would remove. For fsck, it would just report
-  problems. It's OK to do any amount of reading.
-
-* "obnam restore" should verify checksums of restored data.
-
-* Generations should store counts of files and directories, and total
-  size, and size of added data in that generation, and maybe other 
-  statistics.
-  
-* "obnam backup" should do checkpoints every so often when doing
-  a big backup.
-
-
-Wild ideas
-----------
-
-* Key management needs to be designed. Which keys, on which machines,
-  how are they changed, should a passphrase be used, etc.
-
-* From Andreas Barth: there should be an easy, efficient way to see
-  what has changed from generation to generation.
-
-* From Andreas Barth, Robert Collins: there should be a way to 
-  expire (forget) old generations on the server, without storing
-  the encryption key on the server.
-
-* To find the limits of usefulness of de-duplication at the block
-  level, write a program to find out how many blocks are shared
-  among files in a directory tree. For a given block size, should
-  find how many copies of each block exist at any offset in all
-  the files on the filesystem.
-
-* Suggestion from Robert Collins, for store on-disk data structure.
-  Each generation would produce a single file, in which all the
-  data is encrypted, but there's cleartext outwards references to
-  other blocks, and counts of those references. This will make it
-  possible to expire data without decyprting data.
-
-* When running performance tests, clear caches first.
-  http://smackerelofopinion.blogspot.com/
-  2009/07/dropping-page-andor-inode-cache-on.html