duplicity-team team mailing list archive

[Michael Terry <mike@xxxxxxxxxxx>]

2009/8/4 Kenneth Loafman <kenneth@xxxxxxxxxxx>:
> 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