This is a metabug to define the criteria for calling dmedia "production ready", and to summarize what needs to happen to get there.
Being production ready means three things:
1) The version zero CouchDB schema is finalized, and we're prepared to maintain indefinite backward compatibility with it
2) The version zero hashing protocol is finalized, and we're prepared to maintain indefinite backward compatibility with it also
3) We're highly confident about dmedia's ability to protect the user's data, both because we have complete unit test coverage of the dmedia core, and because dmedia has clocked a lot of time in an abusive test harness without data loss
Being production ready doesn't mean feature complete. When dmedia is declared production ready, it may not be practical for day to day use yet, but it will be *safe* for day to day use. This is a big step that must be taken seriously.
Here's a list of things that I know need to be done:
* Design UX and UI for when an error occurs during an import. The import UX is all about reassuring the user that when the import is complete, you can safely format the cards and move on. However, if an error occurs during an import, we must make this very, very clear to the user. We should touch base with the Ayatana folks so we do this according to best practices. I believe the correct approach is to create a window similar to what the Update Manager does when there are security updates. Contrasting the rare error UX with the common UX is important, so my hunch is the error UX needs to require action (to contrast with the usual non-actionable UX).
* Fix import backend so that when certain errors are encountered, the error is relayed up to UI level code... currently there are cases when the importer will say there were zero files imported, when in fact there are files on the card but some error prevented the import from proceeding... very bad!
* Design UX and UI for cases when there are an insufficient number of copies of any user files [in schema terms: {'origin': 'user'} ]. My hunch is we should have both a very loud "error" condition, and a quieter "warning" condition. For the "warning" condition, say you import files onto a laptop while out in the field, and so at that moment there is only 1 copy of these files (on the laptop's internal hard drive): we should probably convey with something like a red indicator, which if you click it, it gives details of the situation, and advice on how to fix the problem (plug in a removable drive, or connect to internet). Or for the "error" condition, say dmedia just detected a hard drive failure, and suddenly a bunch of files dropped to only 1 copy... we should probably convey with an actionable new window... this is urgent, something needs to be done *now*.
* Have dmedia run continuous background verification. This will take time to tune well as far as when to run this, when not to, and should take into account whether the system is operating on battery power. But in the short term, we should err on the side of too much continuous background verification, because we want as early a warning as possible when something is amiss.
* Design UX and UI for adding a new removable drive into the pool that dmedia knows about. The most important thing is to have a UX that makes sure how dmedia labels a drive matches how a user physically labels a drive. For example, dmedia might store that the drive is labeled "Jason 1TB 2011" and that it's in a green sleeve (say for the color coded sleeves available for LaCie drives).
* Make sure metadata sync is working reliably through Ubuntu One or similar. Eventually we want direct metadata sync between devices on the local network to work, but there are some tricky problems we need to solve there.
* Have native dmedia file server and client complete, advertised over avahi (zero conf). In terms of making sure dmedia can protect the users data, transfer between devices on the same local network is a must have. Fortunately, this isn't much work... but this is something that needs abusive testing in the test harness.
I'm going to file individual bugs for all the above. Any bugs related to this are going to be tagged "production-ready". I'll also go through existing bugs and tag them "production-ready" if appropriate.
I assigned myself to this as I'll take responsibility for declaring dmedia production ready. So if you need a throat to choke ;)
