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?

[hbayindir]

There's a need to have a place (or tags) to track which issues are triaged or not. A Kanban board or a tag in GitHub would be equally nice, but it'd need project access AFAIK.

[emtiu]

In order to keep it simple, we might use a separate issue or the GitHub builtin wiki for this tracking. You can link to issues easily, and there would be no friction from working across different platforms.

[buhtz]

I have no project access and not able to add labels to Issues.

But I understood that the "final" decision about the state of an Issue is up to @emtiu. And this is fine for me.
I just would make a pre-triage starting from the oldest Issues and give my recommendation for each Issue in a comment to that Issue.

Most of the old tickets are able to close because the related code version is out-dated, no feedback from the openers anymore and no time/resources to reproduce the problem (with an old version of BIT).

The technical method on how the triage is documented (e.g. via lables on/off) is up to you.

[hbayindir]

That's also fine from my point of view. One can easily see the triaging comments, and can act accordingly.

[lamyergeier]

@emtiu Can this project be made cross platform? Many be this can be achieved if the GUI and CLI backend code can be separated? Backintime on OSX · Issue #873 · bit-team/backintime

Also, the cron dependency can be separated as may be others want to use Systemd or Launchd (on macos) to do automatic backups.

What do you think?

[emtiu]

It's been a few weeks since this discussion started, I was invited into the Github team for maintenance and tried to contribute by triaging bugs and encouraging others to do the same. But from what I've seen, I have little hope for this project.

First off, I'm really sorry to say that I have too little time to invest to make a difference. It might have worked out with more people involved, but that didn't happen. In any case, while triaging and testing are helpful, what really matters is coding.

Sadly, no coding is happening. I'm not at all familiar with the codebase, and I don't want to endanger thousands of users' backups, in many cases going back years and years, by making uninformed changes. Relatedly, there's repository maintenance, code signing and integration/testing to be done—none of which is happening.

Clearly, backintime is being used and loved by a great number of people (including myself). But it's obviously going nowhere, and quickly falling out of compatibility with recent versions of rsync and Python, with no improvement in sight.

[hbayindir]

Actually, I had enough time to triage 5-10 bugs per day when we talked about it, but my workload can change wildly in a whim, and it's what happened here. I personally didn't forget the promise I made, but currently I can't devote any time for any personal task.

Back in time is an "infrastructure item" for me and keeping a lot of things running, so I can dive into the code base if I have to. However I can't do it this week.

Maybe we can try outreaching to people?

[buhtz]

I would suggest to open a simple mailing list for internal development/maintaining discussions. I think there are a lot of questions (e.g. on my side) and things that we should talk about. But I sense a lot of will to contribute to the project. But first we should clear up some things in the "team" to build a team with respect to the individual resources (time and expertise) of all persons involved.

I would be really happy if Germar would join such discussions, too.

For a mailing list I would offer to open a list on the Sympa server of the DFN (German Research Network). Or you have other suggestions? I think also python.org offers mailman3 lists which are usable via web interface also.

If you don't like mailing list we could use GitHub's "Discuss" feature if you want.

[hbayindir]

I agree. A mailing list would be great. If all else fails, I can host a simple mailman 3 list on a VPS, and make it public (on my expense). However, a proper mailing list with a nice domain would be probably better, to make its place permanent. If someone has the domain, I still can host it.

I agree we need to discuss how to move forward. I'm experienced in Linux, python3, rsync and all around system administration. I'd love to help as my time allows.

[buhtz]

I will wait for response of the others. But I would say using the python.org mailman3 instance is the best place currently.

1. As name I would preserve bit-dev instead of backintime-dev. ;)
2. I would create a "private" list. Only members can read/write and read the archive.
3. But on the other side I would accept each new registered member to the list who doesn't look like a bot. ;)

[hbayindir]

But I would say using the python.org mailman3 instance is the best place currently.

I also agree. It's a Python project, and one less thing to maintain.

As name I would preserve bit-dev instead of backintime-dev. ;)

Since Back in Time is about moving bits and bytes around, I also agree with that :)

I would create a "private" list. Only members can read/write and read the archive, but on the other side I would accept each new registered member to the list who doesn't look like a bot. ;)

It makes sense, but making the list "readable by anyone but posting needs registration" will make more sense in the future, esp. after things get moving. It'll prevent people to register just for reading things, keep information public and management of users easier, IMHO.

[buhtz]

OK, the list [email protected] is up and running.

I will post an introduction to my self in the next days. Please take care to read content in the list archive to be up to date

Subscribe via email or web-frontend.

This are the current settings. Of course everything is debatable as everything else. ;)

• Subscription currently works without moderator approval. I will change that later because of spam.
• Archive is members-only. Not sure if a "simple" list subscription is enough to read the archive or if you need an account on python.org.
• Member-list is moderator-only.
• "Munging" is set to "Reply to List" to prevent duplicate messages.

[ghost]

Thank you all for taking up this task. I have been using BiT for a few months and I am very happy with it. It does the job great.

[caco3]

I am glad that @Germar finally made the step to open the project to others. As mentioned already 2 years ago (#1119) I am also willing to invest my knowledge into this.

[thwaller]

I am late to this conversation, but I also use (have used really) BiT. Over all, I have always liked it, especially in conjunction with Timeshift. I have fond as of late that the softwares are almost more trouble than benefit. It is hard to grasp why a user file level backup becomes problematic. While I do like BiT, it is a front end to rsync, and could be replaced by FreeFileSync in most cases or even just rsync itself.

I believe that the recent lack of activity and support (all due respect to all) might be explained given the other options available. I personally like the GUI BiT provides, and I really enjoy the OS integration Déjà Dup provides (but it offers no features, options, flexibility, etc).

I am a former Ubuntu user, currently a Fedora user.

[hbayindir]

Thanks for the insight. However I think there's a misunderstanding about BiT itself. Let me try to clarify.

While I do like BiT, it is a front end to rsync, and could be replaced by FreeFileSync in most cases or even just rsync itself.

Actually no, BiT is a tool which uses rdiff as its foundation, and builds upon that. It provides differential backups with some additional features:

• Can operate completely headless, which is a boon for servers.
• Takes differential backups and only stores changed file, which is good for space management.
• Can consolidate older backups (a-la Apple Time Machine), which again saves a lot of space.
• Can manage free space, backup count or both.

This is the space part only. There are other advantages too.

• Can automatically backup to remote locations or external drives with interval, when they're plugged in (wonderful for laptops)
• Can have multiple profiles for different scenarios (I run with four, for example)
• Can encrypt backups
• Most importantly stores backup setup with backup itself, so you don't need to backup anything.

Yes, KDE and GNOME has their own backup solutions, and they're very good, but BiT is a desktop/distro agnostic solution and is very robust. My installations run without any user interaction, but the capabilities of BiT is more than skin deep, and some of us run this thing on their servers.

So, BiT is not irrelevant software. It just has alternatives, and if you've found one which fits your needs, that's indeed great.

Hope this clears things a bit,

Cheers.

[thwaller]

Thanks for the reply.

So, BiT is not irrelevant software. It just has alternatives, and if you've found one which fits your needs, that's indeed great.

I did not intend to state that it is irrelevant software, although I can can see how my comments could be taken in that way. I really do like BiT. It was the first solution I used when I changed to Linux from Windows and still give it respect. I understand the advantages and considerations you have provided.

I appreciate the work done on this software, and I see each and every alternative as a value. I hope BiT comes back stronger than ever. While I am capable of doing all in the terminal, a nice GUI is convenient.

[buhtz]

Btw: That is the Issue I mentioned in the mail. 😄 This should be referenced in an upcoming HISTORY.md ;)

[emtiu]

I'm closing this Issue in celebration of our finished re-triaging 🥳

Since June, we have reduced the number of open Issues from about 430 to less than 210, and labelled all remaining Issues. We have identified the most pressing bugs and labelled them as High . We've started to improve testing and fixed some minor bugs on the way (see https://github.com/bit-team/backintime/blob/master/CHANGES).

We have been unable to contact @Germar so far, but we're continuing to work on bugs and Issues. We hope to release a new version with the most important fixes in a few months.

[rtevans01]

Sorry to reopen this thread. I have a suggestion. How about making a start page(like Thunderbird) in the right side panel of the UI. You could use it to solicit support for BiT in the form of volunteer devs, donations, language translations, promotion, etc. You could also use it to post news or make announcements. An option would be available to disable or limit it to show only after updates if users get annoyed with it.

Seems like a worthwhile effort given the circumstances.

[buhtz]

Generally a nice idea but needs further discussion its details.
I would recommend to discuss this first on the bit-dev mailing list instead of opening a new issue about it. You reach more opinions on the list.