Next steps for rdiff-backup

[EricZolf]

Hi,

after our recent discussions about the future of rdiff-backup, 
compatibility back and forth, etc, I had to think about this before 
taking a decision.

Two points were important to me:

1. as maintainer, get new participants to the code, I don't have a lot 
of time and I'm a liability if I'm the only one understanding the code. 
I want to be able to leave the project at any time with the good feeling 
of someone being able to take over.

2. as user, speed is my main issue with rdiff-backup, it could surely be 
faster (and I don't think anybody would complain either), else it does 
what I expect. And it is a principle of (non-commercial) open source 
that you're motivated as maintainer by what you need as user.

So, in order to reach these two targets, I must:

1. simplify and document the code properly
2. make the code more modular so that people can participate without 
having to understand the whole code (plugins architecture or similar)
3. even better understand the code to be able to optimize it
4. assuming parallelization and/or async I/O are on the path to better 
performance, it'll be a complexification of the code, which can only be 
successful if the code has been greatly simplified beforehand

Looking at these criteria and adding my own limited availability, I 
decided that:

1. the current 2.2 code will be maintained frozen, with only bug fixes 
and necessary adaptations, e.g. due to newer versions of Python. No 
change will be done if it isn't requested by an user or package 
maintainer through an issue.
2. I'll start to work on the 3.x version, doing whatever is necessary to 
reach my above objectives without considerations for backward API 
compatibility. I still plan to have continuously working versions with 
CI/CD pipeline etc, and it will be an evolution more than a revolution. 
There should be a tool to migrate old repositories to a potential new 
format, but it's not a promise (this said, I plan to keep similar 
concepts, so there shouldn't be any reason for not having such a tool).

I'm not yet 100% decided but I think 2.x will become a branch and the 
3.x development will simply happen on the master branch, where most 
activity will be visible (not that people and/or statistiscs start to 
think that rdiff-backup is dead or so). I also have the idea to have 
weekly releases so that people can more simply try new features.

If someone wants to volunteer to maintain the 2.x branch, I'd be more 
than happy to help him/her onboard on this important task. I don't want 
to put pressure on myself or anybody, but it probably would be an 
endeavor for 2-3 years based on my past speed.

Feel free to comment, but my decision is pretty much taken, for the 
reasons listed above.

KR, Eric