Future of Restic development/maintenance

I understand that the main developer is busy with a recent move, etc… I also understand that there are others who have commit access to the repo that were intended to help keep the project moving in his absence.

Are there any plans for others with commit access to merge any PRs? I could understand them being hesitant about merging any big design/architecture changes, but it would go a long way if they could merge small bug fixes, documentation updates, and other housekeeping type PRs.

Here is a good example of one https://github.com/restic/restic/pull/2329.

There are quite a few other PRs like this that do simple things or fix small bugs that if released would make a difference for people using it.

For those of us interested in helping out… Who should we talk to? What is the best way to jump in and help?

9 Likes

First, welcome to the forum!

I’ve been sitting on a reply to your post for a few days, and I’m still not sure what a good response is, so I’ll just write my thoughts down :slight_smile:

I’m done with the move and I’ve recently set up my desk in a new home, there are still boxes all around me. In addition (as some of you may know), I have two small children who have been demanding a lot more attention the last couple of months. On most evenings after a full workday at my dayjob I don’t have the energy to do anything but sit on the couch for a bit and go to bed early.

I’ve started restic to scratch my own itch, and it outgrew even my wildest expectations! It is a great exercise in thinking large and small and scaling something. I really like working in Go, and I love the community that we’ve built over the last five or so years! There are people who stay on the forum and help others because it’s a nice place to hang out. That’s very important to me.

Then there’s the other side. I’ve been working on restic in my spare time, for fun. I don’t know if you’ve ever heard about something called “maintainer guilt” and the toll it takes on people doing Free Software in their spare time. This article captures the feeling very well, although I like to think that I stop working on software early enough so I don’t get grumpy or overwhelmed. In my opinion it is very important that I like working on restic, otherwise somebody else needs to take over. The problem with larger PRs is that it takes a lot of energy and concentration to go through them. Reviewing code is harder than writing code (at least for me, which surprised me a lot). On most evenings, even if I’m working on restic, it is hard to review larger PRs, so I postpone it. Next time, I’m feeling guilty for not having done a review in time, which makes me feel ever more guilty. Rinse and repeat.

From the beginning, I created the restic organisation on GitHub so that it is not tied too much to my personal account. There are a few people I asked if they’d like to help with maintaining restic, they can merge PRs and label and close issue. There are others (two personal friends) who even have admin privileges, so they could carry on working on restic or appoint new maintainers or even admins should something dramatic happen to me. Besides restic being Open Source, I made sure that the repository format is well documented, so people can reimplement the program should they have the need to pull some data out of a broken repository which restic is not able to read. I like to think that sometime somebody else comes along who likes to take over restic, so I made sure that’s easy to do :slight_smile:

There are several people who could do this, I guess they are busy as well (and that’s entirely fine in my opinion). I trust them to know when they can merge something.

That’s an excellent question that I don’t have an answer to. Reviewing PRs is always a good idea, and people have already started doing that (thank you very much!). Unfortunately, I need to do some housekeeping in order to get the CI system back into shape, afterwards that should be easier.

So, my plan so far looks as follows:

  • Release a new version of restic
  • Rework the CI system to use GitHub Actions instead of Travis/AppVeyor (now that it is out of closed beta)
  • Look through the PRs and merge the easy ones

I’ve just discovered that this website provides some nice starting points to easy Open Source maintainers’ burdens a bit: Best Practices for Maintainers | Open Source Guides

Anything I’ve missed?

18 Likes

Please don’t be stressed. Restic is wonderful as it is. I’ve restored quite a bit of data using different software over the years and never did I have such a good feeling doing it - and so much fun :wink: So please feel like a hero (or a rock star if you prefer).

New house and two little kids sounds familiar by the way. That alone is more than most can handle. And kids time is worth more than anything you will ever have.

What about finding help in institutions/companies using restic, like CERN?

4 Likes

One thing that I personally feel is important is to help answer people’s questions about usage and when they have problems of the type that have been seen and answered before.

Be it just general usage, or things like unexpected situations or even corruption in the repository (in which case one might need help to diagnose the cause, check hardware, etc), a lot of this has happened before and the procedure is the same this time again :slight_smile:

With that also comes documentation. The restic documentation is in need of improvement, both in clarifying and polishing the existing chapters/information, as well as adding more to it to cover more of the common use cases and questions that pop up every now and then.

So, feel free to pick some issue and file a PR, regardless how small it is :slight_smile:

4 Likes

Rework the CI system to use GitHub Actions instead of Travis/AppVeyor (now that it is out of closed beta)

Hi! I can help with this. I have some experience in working with GitHub Actions. How may I start?

Thank you for the responses and all the work put into restic! I didn’t intend to make anyone feel guilty.

Perhaps the best thing @fd0 would be to have a goal for someone other than you to do a release. That will increase other’s confidence to help out and work on it.

@fd0 Sounds like you have a volunteer to help with GitHub Actions. I can help look through the issues and PRs and triage them into easy ones or ones that might require longer reviews.

My experience is if you can’t motivate yourself to review a large PR then the PR is probably too big! It isn’t bad to ask someone to break it into smaller PRs that can be reviewed independently.

Thank you again for your work and time you have spent volunteering.

3 Likes

As one maintainer of a busy open source project (rclone) to another, please accept my sympathy and best wishes.

I know exactly how you are feeling - I’ve been there and done that!

I’d 100% agree with this. Reviewing PRs is hard. My own solution has been to make the PR reviews I do lighter. This means that sometimes bugs slip through and designs are bad. These can all be fixed though and often are by a different PR from someone else! I figure that is what the beta testing is for…

I can’t commit time to restic alas, but if you want to chat it over more you’ve got my email!

3 Likes

It would be great if you could try to help with some of the debugging and issues that need actual work. Im not saying triaging isn’t important, but labeling issues is probably of less priority than actually trying to resolve them :slight_smile:

I’ve gone through a few pages of issues and some PRs and managed to clean up a bunch of them, but there’s still many to go. You could start on page 4 in the issue list if you want :smiley:

1 Like

I think at least getting feature requests labeled as feature requests would help. It would save everyone a bunch of time I think if they were labeled. Then we know which ones to look into and help triage and which ones are OK to go unanswered.

1 Like

@fd0, first, thanks for restic! Your life and your kids are more important than anything else :slight_smile:

One thing you might consider is to setup a stale bot, both for the issues and for the PRs. Stale bots are configurable, and normally they work like this: after a period, they ask on the issue or on the PR if anybody is still interested in it. After a second timeout without response, the issue or the PR is closed.

Granted, they are just stale bots and do not solve the triaging or the reviewing problem of PRs. On the other hand, they contribute to close things that for many reasons cannot be solved.

And thanks for the link to https://opensource.guide/best-practices/, very good.

1 Like

I think this solves a different problem we are faced with right now. Not to discredit your idea, I know this is a thing and some projects make good use of that.

FWIW, I agree. There’s a lot of issues that are still relevant in terms of feature requests and what not, that we don’t want to archive. I think we can manage without a bot for this.

I’ve given this a try already, you can check out what I built here: Use GitHub Actions for CI by fd0 · Pull Request #2475 · restic/restic · GitHub

Hello @fd0 and other Restic users and contributors,

Thanks for all you’ve done! You’ve already given the world a great open-source program that works incredibly well, and provides much peace of mind!

@fd0 Please know that family matters and personal matters are far more important than working on this open-source project. I hope it will be picked up by those with the technical knowledge to continue its work, but if it has become a burden, it should not be your concern any longer. You’ve opened all the doors you can, and you’ve given out the rest of the keys. Now it’s up to the community to keep going. Even if you take a month, a year, or several years off, I’m sure the community will be happy if you return. Please know though, that you do not owe us anything! You’ve given so much already! I hope we can repay the debt we owe you by giving you space while you need it, whether you come back to the project or not!

Thanks for all you’ve all done! This project has been, and will continue to be, a very important one in my day-to-day life. Please, put your family and yourself first! Whether or not you are able to return in the future is not something to worry about now. Either way, you’ve already created an amazing project. Maybe you’ve never felt confident in releasing a 1.0, but v0.9.5 is far more stable, reliable and performant than many, many other backup softwares I’ve used, and software in general. I hope that, whether you choose to stop now or come back later, you can always look back at your accomplishments with pride and joy, rather than guilt! Again, you owe us nothing!

A person who has given so much should never feel guilty about needing time to help their family and/or themselves. I hope that your family gives you strength in the long-run, even if it feels like you need to use all your strength right now for them. I know it’s very difficult now, but being a good parent will be extremely rewarding in the long-run. I hope you get as much as you give, and I hope that things get less chaotic for you and your family. Being a parent is far more important than running an open-source project. Please, do what you need to do, and if you get the chance, please keep in touch.

Thank you for everything you’ve done!
You’ve made the world smile, I hope we return the favor now,
Dan

1 Like