2009/8/4 Kenneth Loafman <[email protected]>: > What do you think should be the next major development thrust in > duplicity? I've got some generic ones, but you're in the trenches with > more users than I see, so let's hear from you and get something going.
Quick reply, maybe a more full one in time. First, thanks for asking. :) > My ongoing objectives, not in order of importance: > > 1) Get async working so that we can better overlap processing and > network activity. This includes thread-safing the backends and getting > multiple uploads going at once to speed processing. > > 2) More testing and more test cases, primarily full-system tests rather > than individual unittests. I'm a huge fan of this. I've been recently expanding my own deja-dup testcases. Which may or may not be interesting to you. I use ldtp's python bindings to drive the UI. And I can easily test against multiple versions of duplicity (including duplicity bzr). You already have your own framework, so my few scripts probably aren't useful, but just throwing it out there as a comparison point. It would be a huge win for me if I could have the time to run my scripts before a release happens. Or if you were comfortable enough with it, running them yourself. This would help raise red flags if a release would break deja-dup. In fact, having some sort of formal 'code-freeze a week before a release' may be useful for both my own testing (and maybe user testing, could announce and put in a testing PPA) and for translators to have time to translate new strings. But that's more about process than new development. > 3) Better documentation - a new web site, maybe, or is it OK to leave > duplicity on nongnu.org if we're not using them for much else? Either > way, there needs to be a FAQ section, use cases, troubleshooting, etc. A wiki might be good for this. I searched for a wiki provider, and sort of came up short. I ended up sticking stuff on wiki.ubuntu.com, but that's really probably not the best place. > I'd like your ideas as well. Negative as well as positive. Are we > going in the right direction, or what? I'm happy with recent direction. Your willingness to make things work 'out of the box' (e.g. making sure archive dir is in sync such that the user never has to manually futz with it) has been great. That sort of focus is what's needed to let front ends like mine go about their business. An ongoing effort to make sure that all messages have numeric codes for frontend-consumption would be nice. Or maybe just make sure new ones have them. Checking if there's enough space before restoring would be nice. Letting a frontend check how big a restore will be before doing it is also useful (above and beyond duplicity checking itself). Right now, I'm happy, but I will email if I think of more. -mt _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
