Re: [rdiff-backup-users] Future of rdiff-backup: Python 3 migration and project maintainership in general

[Eric Lavarde]

Hi,

On 01/08/2019 21:47, Otto Kekäläinen wrote:
> > Forhttps://github.com/rdiff-backup/rdiff-backup  you appear to have
> > forked Seravo's fork, which is a fork of Sol1's. Would it be better if
> > we deleted that repo and I can transfer the existing repo to the
> > rdiff-backup organisation? I think then we get an auto-redirect and no
> > "forked from" notation.
> Sure. Please proceed with doing that.

@Andrew, yes, please do this, I don't have enough rights to do it myself.

> Please ping me when you are done so I'll proceed by "upstreaming" the
> patches done in Debian, and after that I'll finish Eric's PRs review.

Thanks, I'd really like to get it out of the way. Such a huge PR makes 
me nervous.

As for the Debian patches, I guess you mean the ones under [1]?

* 01_fix_restricted_test-server_option.diff - seems to be already in master
* 02_python_2.6_deprecationwarning.diff - addressed with my PR
* 03_fix_hardlinks.diff - not sure what it fixes but why not. Could be 
done after the Py3 merge though to avoid conflicts.
* extend--no-compress-files.patch - minor, why not, whenever.
* librsync2.patch - already addressed in master.
* rdiff-backup-enodata-fix.patch - I've encountered the issue it 
addresses and am currently analyzing, just ignoring the ENODATA seems to 
me to only hide a potentially deeper issue: I haven't yet understood how 
it comes to this issue, which in my case comes when trying to regress a 
failed repo with EAs and/or ACLs involved. I would recommend leaving it 
open for now, until we know better what we're doing.

KR, Eric

[1] 
https://salsa.debian.org/python-team/applications/rdiff-backup/tree/debian/master/debian/patches