duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

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

I think I should do that.  Put the changes up in bzr, but not do the
actual release for a week.  That way we can test it more.

> But that's more about process than new development.

Process improvements aid development, guaranteed.

> 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 was thinking that a Wiki might be just the ticket and wiki.ubuntu.com
would be the way to go if they don't mind.  Of course, $10/month for a
web host is not bad either.

> 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.

That has been a sore point with the archive-dir option for a long while.
 I think we've seen the last of that one.

The one major problem with working out of the box is that errors tend to
be fatal during backup.  Most of that is due to the process used to make
the tar files.  A single file stopped due to error would leave a piece
in the backup and would not verify.  Still working on that, its messy.

> 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).

So far, so good on the feedback.  Don't be afraid to complain if I'm
doing something wrong.  I guarantee it won't be the first time.

...Ken