Re: Next steps for rdiff-backup

[Patrik Dufresne]

Hello Eric,

I think it's the best direction to branch out a future version 3.x. It
gives more space for innovation and should greatly improve the speed of
development.

As much as I would like to dedicate more time to rdiff-backup itself, my
hands are really full with Rdiffweb and Minarca.

Thanks alot for all your work.

+1 for weekly releases



Le sam. 6 mai 2023, à 07 h 08, EricZolf <ewl+rdiffbackup@lavar.de> a écrit :

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

-- 
*ATTENTION: Je serai en vacance du 6 Mai au 21 Mai 2023.*
*ATTENTION: I will be on vacation from May 6 to May 21, 2023.*
IKUS Software
https://www.ikus-soft.com/
514-971-6442
St-Colomban, QC J5K 1T9