duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

any reason why you sent this to the "inner circle" list but not to duplicity talk for a wider audience?

On 19.11.2013 19:13, Michael Terry wrote:
> It's been 10 months since we last talked Python 3, and you all know how much I love talking about it.  So I  have another Python 3 proposal.
> 
> The last plan-of-record was to keep 2.4 support and use 2to3 to generate a python3-compatible version of the source on the fly.  Which is a bit of an all-or-nothing conversion.
> 
> I made such a branch, and sent an email to duplicity-talk asking for testers, but no one bit.  

yeah, it amazes me all the time how a software like duplicity with so many users around the globe does not attract developers like light bulbs flies during the night. but ok, shell only backup is kind of a niche and duplicity more or less runs stable (so no reason for people to join the mailing list). 

>And because it's an all-or-nothing approach, the diff got a bit large (2to3 can't handle some of the trickier aspects like unicode handling, so there needed to be a string abstraction layer).
> 
> So, I'm now revisiting the other idea we had, of requiring python2.6 and bumping the version to 0.7.  We'd keep the 0.6 line open for critical bugs only (I'd personally suggest defining critical as "data loss").

Ken's decision, but i doubt he'd like the additional work load. aside from the fact that contributors would have to provide two branches henceforth.

but starting a 0.7 branch for further development sounds reasonable and we can keep 0.6 around as "stable".

btw. Ken, we should remove the 'beta' status from the website! duplicity far from perfect is definitely not beta anymore.
 
> This way, we can slowly introduce __future__ imports to the code base and eventually the 0.7.x line would work in python3 as well as python2.  But it would be a gradual thing, easier to test and easier to review.

do future imports really work with any old python version? or are there versions that e.g. didn't have the 'unicode_literals' .. so that using future imports will enforce minimal minor versions for the python runtime e.g. you have to install python 2.6.10 'cause 2.6.1 didn't have it at that time?

> There are clearly still invested RHEL5 users, as my recent quick poll on the mailing list showed.  But I doubt RHEL5 users are looking for new features.  They've been on RHEL5 for six years, they probably value stability most and have their backup routine locked in already.  I think a critical-only 0.6 maintenance lifetime would serve them well.

ideally they should have tested their routines so thoroughly that it should be highly unlikely that they discover a data loss bug suddenly. but, yes, seeing that duplicity runs on "low maintenance" since years, let's phase out 0.6.

> 
> Ideally, we'd see a release of 0.6.23 before switching, since it has a data loss fix in it already.
> 

yeah, let's clean house as best as possible before that.

Ken: any idea about all the branches on launchpad? what to do with them? keep them for reference?

..ede