Is this project dead? Taking stock of pressing issues, Discussion welcome

[emtiu]

I love backintime, it's been the backbone of my multi-level, multi-device backup strategy for many years now. The backups are simple, resilient and portable. In this regard, I think it's much superior to borg, restic or bup (which absurdly seem to think that everything in the world should be stored in the form of a git repo).

But after upgrading my system and trying to set up backintime >=1.2, I'm shocked at the sorry state of it:

• The new default of rsync --perms is causing mayhem, most notably with "New" permissions handling in 1.2.0 causes re-backup of files that haven't changed #988 (which points to a design flaw) and Files with permissions r--r--r-- being repeatedly backed up #994 (which points to an implementation error). It's likely that many users are running into this issue, but cannot identify the cause and just give up, as probably happened for backintime gets slower with new incremental backups #1132.

  • Make v1.1.x style permission handling configurable via expert settings. #1086 and Remove new permissions handling #1128 are hacks to restore the old behaviour, but neither has been picked up.

• backintime does not work with Python 3.10, as evidenced by AttributeError: module 'collections' has no attribute 'MutableSet' #1210 and backintime available for 22.04 ? #1223. Python 3.10 is the default in the upcoming *buntu 22.04 LTS, so this is very significant.

  • There seems to be a trivial fix given in Make tools.py work on python 3.10 #1174, but it hasn't been picked up.

• There seems to be no maintenance of this github repository's issues and pull requests, as evidenced by:

  • trivial fixes like Small typo in French #1077 not getting picked up

  • silly issues like Just asking, where is the software available for download? #1160 not getting closed

  • completely resolved issues like fixed ita typos #1123 being left open

I love and rely on backintime enough to consider creating a fork to maintain basic functionality, but that won't help many others who install it from this official source. With backintime not even running on *buntu 22.04 LTS and the fix not being implemented, there's probably not much time left before distributions drop backintime completely for being unmaintained. That would be a great loss.

I'm willing to help fix the code, and also with basic housekeeping of this repo's issues and pull requests. But I'm not sure is there's anyone left here doing any actual maintaining, and so I'd like to know what the official team, or other loyal users are thinking before committing.

[gsker]

I too rely on it.
I was also wondering why I didn't see 1.3.1 in debian testing or impish --
(1.3.1 contains the trivial fix for the MutableSet breaking change) and I found this likely cause for that:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003776
That doesn't address the github repo maintenance though.

I wonder if @Germar or @dinoboy197 or @LanceGundersen have the ability to delegate this maintenance...

[emtiu]

I wonder if @Germar or @dinoboy197 or @LanceGundersen have the ability to delegate this maintenance...

That would be ideal. Cleaning out the issues and pull requests could help development and testing focus on the important bugs. Labelling issues, assigning milestones, tracking testing … there's a lot the community could help with.

It would also help the maintainers see more clearly which patches and fixes are the most urgent.

[colintedford]

This question was discussed twice in 2020:

• Is BackInTime dead? #1088
• Is BiT truly dead? #1114

[emtiu]

This question was discussed twice in 2020:
* Is BackInTime dead? #1088
* Is BiT truly dead? #1114

It was indeed, and nearly two years have passed since then. The grave bugs introduced by 1.2.0 such as #988 and #994 have not been tackled.

Also, the state of this repository has deteriorated further. This is evidenced by @gsker's report of the version number mixup that broke distro packaging: 1.3.0 followed v1.2.1 for no apparent reason. Not to mention to mention hundreds of open issues with next to no housekeeping happening (7 issues closed in the past ~8 months, while ~45 were opened). Not even #1088 itself has been closed.

The question of the maintenance and future of this project is now even more, not less, urgent.

[LanceGundersen]

I have been tagged here a few times over the years and I'm not sure why 🤔 I'm a frontend dev primarily but am not afraid of diving in and making things worse on the lower levels. Do I have permissions that could be put to use? If so and someone wants to bring me up to speed I'm happy to help.

[emtiu]

I have been tagged here a few times over the years and I'm not sure why thinking I'm a frontend dev primarily but am not afraid of diving in and making things worse on the lower levels. Do I have permissions that could be put to use? If so and someone wants to bring me up to speed I'm happy to help.

Probably because you're one of four members of the https://github.com/bit-team :) Not sure if you could nominate further members.

By the looks of it, there isn't any "leadership" left to make such decisions anymore. But maybe, given a few more days, one of the remaining two(?) active members of the team will chime in.

[Germar]

Hi Michael,
I just invited you to be member of bit-team dev and doc. With this membership you're able to make changes in all repositories including issues and PRs.
I'm sorry to say, that I don't find the time for working on BiT anymore. And I also kind of lost the interest on working on it, too. So it would be great if you would like to take over further development for this project.
AFAIK my own GPG key is necessary to push new versions to PPA (https://launchpad.net/~bit-team/+archive/ubuntu/stable). Not sure if I can change this. But I can publish new versions on the PPA if you give me a ping.
If you need further help I'm happy to assist.
Kind regards,
Germar

[emtiu]

Thank you, @Germar! I will be travelling for a few days, but then I'll get started sorting through the Issues and Pull Requests here. I'm happy we're getting a good chance of keeping this project alive :)

[nodiscc]

I too rely on Backintime for many years on desktop (rsnapshot on servers which also uses rsync and hardlinks 👌 ).

It is not much but I can help with triaging/organizing issues/PRs, which could help in determining a first milestone (bugfix release?). Later when I get some time I could help setting up an automated test/build chain. And help with testing.

[hbayindir]

Hello,
I too rely on BiT on quite a few systems and it works very well. I might not have all the time for development, but can help with triaging, testing and occasional development.

[emtiu]

Hello, I too rely on BiT on quite a few systems and it works very well. I might not have all the time for development, but can help with triaging, testing and occasional development.

That's great to hear! I think cleaning up the issues and pull requests here would be a great start. There are some useful tags, but they haven't been applied to new issues in a while. If you could dig through some issues and sort out which are no longer relevant/duplicates/needsinfo etc., that would be very useful. Just reply to the issues in question, and I can follow up by closing/tagging them.

[hbayindir]

Thanks for the prompt reply. Of course. That'd be a pleasure to help a project I which makes an essential part of my infrastructure.

[buhtz]

cleaning up the issues and pull requests here would be a great start.

I can help here, too. Did that in that past but only Germar was there to react on my recommendations.

Do I understand it correct, that you know have "admin access" to the project?

There are some useful tags, but they haven't been applied to new issues in a while.

Looking onto the goal to re-triage all open issues.
Can we find a way to differentiate between now-triaged and not or old-triaged?

For example we can have a tag "re-triaged" or "triaged2022".
Or the other way arround add a "needs-re-triage" to all Issues at once. And then remove it step by step while re-triaging.

[emtiu]

cleaning up the issues and pull requests here would be a great start.

I can help here, too. Did that in that past but only Germar was there to react on my recommendations.

Do I understand it correct, that you know have "admin access" to the project?

I was invited to the Github team, so yes I do. I'm not (yet) confident enough with the code to use it for commits, though. But triaging tickets, and maybe setting up some testing infrastructure, would be a good fit.

Looking onto the goal to re-triage all open issues. Can we find a way to differentiate between now-triaged and not or old-triaged?

For example we can have a tag "re-triaged" or "triaged2022". Or the other way arround add a "needs-re-triage" to all Issues at once. And then remove it step by step while re-triaging.

Both are good ideas. Do you need me (i.e. someone with write access) to create tags, apply them, or both?