GNOME Inclusion Proposal

These are working notes for a possible bid to be an included module in the GNOME 3.0 Desktop suite.

See ReleasePlanning/ModuleProposing.


GNOME lacks a backup story.

OK, So What's My Story?

First, I'm specifically proposing my own pet project Déjà Dup, which is one of many backup programs out there. I think it's pretty sweet but would also like to open the floor for comparisons to other programs. Maybe mine isn't the best fit.

Déjà Dup's story is that it only tries to be a data backup program for disaster recovery. But aims to be the best little disaster recovery program there is.

It is designed to do the "right thing" without getting in the user's way. See the mission statement.

It encourages backing up to a cloud service. It encourages backing up on an automatic schedule. It is designed to target the not-very-computer-literate. It prefers to backup too much rather than too little. It integrates well into GNOME.

It's a frontend for the command-line backup program duplicity.

User Trust

If the user doesn't trust their backup system, what's the point? A backup system is only as strong as its restore, but by the time you find out that your system fails the restore test, it's usually too late.

Backups are tricky. We're responsible for user's data and they will be very mad if we lose it. Maybe GNOME doesn't want to get into that business, but we can always point to the boilerplate disclaimer of fitness for any particular task. :)

Déjà Dup is a wrapper around the already-proven command line tool duplicity. It has a suite of automated GUI tests. So I trust it (and use it). But these facts aren't user visible.

I suspect user trust is a matter of time and usage. Unfortunately, Déjà Dup hasn't been around very long (about a year -- about 2 years by the time of GNOME 3.0).

Why Not Just Live in the Cloud?

More and more of our lives are being stored remotely in Internet services and clouds (flickr, facebook, Ubuntu One, rhapsody). This seems to reduce the need for a backup of your data, if it all lives in the cloud.

However, I don't think backup can ever be quite replaced. Unless a cloud system is specifically designed to hold your data, encrypted, with snapshots, with promises of availability and no-data-loss, there is still a strong use case for your own backup.

  • Most cloud services only keep track of your current files. If you delete a file and later realize you need it a month ago, you're out of luck.
  • Cloud services tend to be fragmented. You don't have easy access to all your data from one place.
  • There will likely be data that you don't trust the cloud to hold.
  • You only put a weaker version of the data in the cloud, but keep the pristine version locally (photo upload to flickr).
  • You may have large amounts of data that aren't appropriate for upload.

Of course, there's no reason you can't store your backup files in the cloud.

I look forward to the sci-fi future where everyone uses thin clients into server farms that offer transparent data safety and duplication. I won't stand in that future's way for love of my own code. But in the meantime, I think a backup program is a useful offering.

What Does Backing Up Give Me?

There are already different solutions for the basic thrust of what backups do (data protection).

  • Rollback to previous versions of files with btrfs or some version of my-filesystem-is-a-vcs
  • Sync local files to the cloud (like Ubuntu One)

But none of those are able to meet all disaster recovery needs (of three main sorts):

  • Revert to old version of file.
  • Recover a small number of lost (accidentally deleted) files.
  • Total system failure.

What many backup systems (and Déjà Dup specifically) provide are:

  • Rollback to previous versions
  • Automatic backups (i.e. no-intervention after initial setup -- if you have to do it manually, you're not doing it enough)
  • Incremental backups (space saving)
  • Encryption
  • Ease of off-site backup (for really bad disasters like floods, fires, or mass theft)


  • duplicity
  • python-boto
  • valac (only for building from the VCS)

Maintainer's Responsiveness

Well, I'm biased, but I think I've been very responsive and active during Déjà Dup's lifetime. There are frequent releases and regular bug-fix-only and translation maintenance releases. I'm comfortable with the amount of maintainer work that GNOME seems to require (point releases leading up to a 6-month release).

However, I suspect that inclusion into GNOME would (by virtue of a massive amount of new users) create lots more bug activity and patch submissions. This would create much more work for me (or at least a sense of obligation to do more work). Ideally I'd get a co-maintainer or some frequent developers? I'm curious about other maintainers' experiences in this regard.


None of GNOME ftp, git, and bugzilla are used currently. Launchpad serves all project hosting needs right now. I'm fine switching to GNOME hosting, but am attached to Launchpad and wouldn't want to switch until approved.

Uses GNOME wiki already.


There are some number of active users, but obviously actual statistics are hard to come by.

Currently packaged in Debian and Ubuntu. No RPM distros yet package Déjà Dup. Duplicity is basically packaged everywhere.

GNOME Community Interaction

No particular overtures have yet been made. I'm excited to work with the various GNOME teams (documentation, i18n, usability, etc). I'm a GNOME contributor from way back and am familiar with the GNOME community on a superficial level.

3.0 Readiness

No deprecated libraries are used.


  • GTK
  • Follows HIG
  • Integrates into nautilus via an extension
  • Uses session dbus 'locking'
  • Uses NetworkManager dbus API to watch network connection

  • Uses gnome-keyring to store passwords
  • Uses gio/gvfs
  • Keeps up with GNOME best practices (like X-GNOME-Fullname and the like)
  • Written in vala
  • Uses gnome-common and gnome-doc-utils

Expected Problems

Missing Features

  • Optical (CD/DVD) backup (bug 391827)

  • Restoring user's set of installed packages (bug 485628)

  • Restoring system files (files that the user does not have write access to -- i.e. we don't currently prompt for password) (bug 307633)

Major Bugs

  • Restoring currently requires way too much /tmp space (basically restores to /tmp then moves to location). I have a plan for fixing this, should happen during 2.30 release cycle.

Lack of GNOMEness

  • Does not yet use mallard

Apps/DejaDup/GNOME (last edited 2013-08-14 14:40:19 by WilliamJonMcCann)