starred/sms-backup-plus-jberkel

Fork 0

mirror of https://github.com/jberkel/sms-backup-plus.git synced 2026-04-25 17:05:59 +03:00

[GH-ISSUE #853] Helping out and triaging #678

New issue

Open

opened 2026-02-26 01:31:19 +03:00 by kerem · 11 comments

kerem commented

2026-02-26 01:31:19 +03:00

Owner

Originally created by @jcrben on GitHub (Mar 15, 2018).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/853

Following up on my offer to help triage @jberkel -

I think I'd need project permissions, yep (dunno much about matrix permissions, some stuff at https://github.com/isaacs/github/issues/311 and https://help.github.com/articles/repository-permission-levels-for-an-organization/). I'm a developer without Android or Java skills so I can ask the right questions and maybe take a glance at a log here or there but don't expect to contribute code anytime soon.

I'd like to see more labels and close more issues. It's best if users report bugs against later versions than the 2015 one in the Play store, and if they can't provide a log, I'm inclined to close after a period of time... for example https://github.com/jberkel/sms-backup-plus/issues/380

Also, we could add a .github/ISSUE_TEMPLATE and add a code helpers badge https://www.codetriage.com/ maybe?

Anyhow, no pressure - I can't promise I'd be very active - possibly only spending an hour or two a month, especially after or while checking my backups 😆

Originally created by @jcrben on GitHub (Mar 15, 2018). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/853 Following up on my offer to help triage @jberkel - I think I'd need project permissions, yep (dunno much about matrix permissions, some stuff at https://github.com/isaacs/github/issues/311 and https://help.github.com/articles/repository-permission-levels-for-an-organization/). I'm a developer without Android or Java skills so I can ask the right questions and maybe take a glance at a log here or there but don't expect to contribute code anytime soon. I'd like to see more labels and close more issues. It's best if users report bugs against later versions than the 2015 one in the Play store, and if they can't provide a log, I'm inclined to close after a period of time... for example https://github.com/jberkel/sms-backup-plus/issues/380 Also, we could add a .`github/ISSUE_TEMPLATE` and add a code helpers badge https://www.codetriage.com/ maybe? Anyhow, no pressure - I can't promise I'd be very active - possibly only spending an hour or two a month, especially after or while checking my backups 😆

kerem added the

help wanted

task

labels

2026-02-26 01:31:19 +03:00

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jberkel commented on GitHub (Mar 15, 2018):

Awesome, thanks again!

I created an initial issue template, feel free to adapt it. I also added you to the project so you should be able to apply labels etc. Stale/"Hanging" issues should definitely be closed. Also let me know if something in the docs is missing, I'm planning to rewrite some of it for the next major release.

I haven't used codetriage.com, interesting idea, I'll add it.

@jberkel commented on GitHub (Mar 15, 2018): Awesome, thanks again! I created an initial issue template, feel free to adapt it. I also added you to the project so you should be able to apply labels etc. Stale/"Hanging" issues should definitely be closed. Also let me know if something in the docs is missing, I'm planning to rewrite some of it for the next major release. I haven't used codetriage.com, interesting idea, I'll add it.

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jcrben commented on GitHub (Mar 18, 2018):

I added the help wanted and good first issue labels since Github does some work with those automatically https://help.github.com/articles/finding-open-source-projects-on-github/#searching-using-labels

Also something that confirms reproducibility would be good - do you have a name in mind? reproducible or something?

I wonder how hard I would present a repro case. When I report bugs, I like to be able to present an actual downloadable case showing the bug, often with a repo and possibly with a VM in packer (packer.io) if it's platform-dependent - dunno if you can do that with Android.

@jcrben commented on GitHub (Mar 18, 2018): I added the `help wanted` and `good first issue` labels since Github does some work with those automatically https://help.github.com/articles/finding-open-source-projects-on-github/#searching-using-labels Also something that confirms reproducibility would be good - do you have a name in mind? `reproducible` or something? I wonder how hard I would present a repro case. When I report bugs, I like to be able to present an actual downloadable case showing the bug, often with a repo and possibly with a VM in packer (packer.io) if it's platform-dependent - dunno if you can do that with Android.

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jberkel commented on GitHub (Mar 18, 2018):

maybe confirmed? repo cases are difficult in general, some of the bugs are very dependent on a specific version of Android, a particular carrier etc. Especially the backup reliability related issues are very hard to reproduce. But some are really "obvious" bugs, and it would be good if they could be labeled as such.

@jberkel commented on GitHub (Mar 18, 2018): maybe `confirmed`? repo cases are difficult in general, some of the bugs are very dependent on a specific version of Android, a particular carrier etc. Especially the backup reliability related issues are very hard to reproduce. But some are really "obvious" bugs, and it would be good if they could be labeled as such.

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jberkel commented on GitHub (Mar 28, 2018):

In preparation for the upcoming release I've just done a marathon bug review session.

Besides the known problems (RCS, MMS, Auto backup) there don't seem to be any major "real" issues. Also thanks @Woi who added relevant context to some of the issues. Let me know if you want project access to help with future triaging.

@jberkel commented on GitHub (Mar 28, 2018): In preparation for the upcoming release I've just done a marathon bug review session. Besides the known problems (RCS, MMS, Auto backup) there don't seem to be any major "real" issues. Also thanks @Woi who added relevant context to some of the issues. Let me know if you want project access to help with future triaging.

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jcrben commented on GitHub (Mar 29, 2018):

Nice! By the way I saw https://blog.github.com/2018-03-28-improved-organization-project-permissions/ - haven't really dug into it

We might want to have another tag for "awaiting information" or something to help us find places where we asked for more information and didn't get it. And ultimately there are automation tools out there...

@jcrben commented on GitHub (Mar 29, 2018): Nice! By the way I saw https://blog.github.com/2018-03-28-improved-organization-project-permissions/ - haven't really dug into it We might want to have another tag for "awaiting information" or something to help us find places where we asked for more information and didn't get it. And ultimately there are automation tools out there...

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@Woi commented on GitHub (Apr 2, 2018):

Project access would be nice. Don't expect continues involvement from me, but at least I could close, link and label some of this old bug reports.

@Woi commented on GitHub (Apr 2, 2018): Project access would be nice. Don't expect continues involvement from me, but at least I could close, link and label some of this old bug reports.

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jberkel commented on GitHub (Apr 3, 2018):

@Woi invite sent. don't worry, there are no expectations on my part.

@jberkel commented on GitHub (Apr 3, 2018): @Woi invite sent. don't worry, there are no expectations on my part.

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@Woi commented on GitHub (Apr 3, 2018):

Cool. Thanks :)

@Woi commented on GitHub (Apr 3, 2018): Cool. Thanks :)

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jcrben commented on GitHub (Apr 14, 2018):

@jberkel just as an fyi - I'm still using this and will help out when I can (including maybe code someday), but I'm not having the issues that a lot of people are e.g. restoring thousands and not motivated to help out with that... I'm fine with the messages archive in email

restoring thousands
UPDATE: glancing at https://github.com/jberkel/sms-backup-plus/issues/868 - it seems that a large restore was successful... still, maybe the app should only cap the loaded number and notify the user that no more will be loaded. It may not be realistic to load an unlimited amount.

I agree with the sentiment at https://github.com/jberkel/sms-backup-plus#faq-restore-many-messages

SMS Backup has not been designed to restore many thousands of messages.

and even https://github.com/jberkel/sms-backup-plus/pull/586 noted that "Restoring a lot of messages by default fails after at least 30 minutes with e.g. timeout of IMAP server" (altho that was in 2015, not sure if you've improved it).

moving away from SMS and supporting countless permutations
Long-term, I want to move away SMS and be using an open-source platform where the messaging protocol is open-source such as Signal or Riot or what have you. I'm also pessimistic about the problem of reproducing problems on the various permutations of platforms, which is minimized if there's a more centralized app.

So I'm also planning to make open-source contributions in that area. Signal can also handle SMS so once it stabilizes a bit more I may switch - altho I'm also waiting for the Signal Desktop to support SMS since I currently use SMS from the desktop quite a bit using Pulse (I also discussed this a bit in the context of reliability at https://github.com/klinker-apps/messenger-issues/issues/101#issuecomment-373424858).

@jcrben commented on GitHub (Apr 14, 2018): @jberkel just as an fyi - I'm still using this and will help out when I can (including maybe code someday), but I'm not having the issues that a lot of people are e.g. restoring thousands and not motivated to help out with that... I'm fine with the messages archive in email **restoring thousands** UPDATE: glancing at https://github.com/jberkel/sms-backup-plus/issues/868 - it seems that a large restore was successful... still, maybe the app should only cap the loaded number and notify the user that no more will be loaded. It may not be realistic to load an unlimited amount. I agree with the sentiment at https://github.com/jberkel/sms-backup-plus#faq-restore-many-messages > SMS Backup has not been designed to restore many thousands of messages. and even https://github.com/jberkel/sms-backup-plus/pull/586 noted that "Restoring a lot of messages by default fails after at least 30 minutes with e.g. timeout of IMAP server" (altho that was in 2015, not sure if you've improved it). **moving away from SMS and supporting countless permutations** Long-term, I want to move away SMS and be using an open-source platform where the messaging protocol is open-source such as Signal or Riot or what have you. I'm also pessimistic about the problem of reproducing problems on the various permutations of platforms, which is minimized if there's a more centralized app. So I'm also planning to make open-source contributions in that area. Signal can also handle SMS so once it stabilizes a bit more I may switch - altho I'm also waiting for the Signal Desktop to support SMS since I currently use SMS from the desktop quite a bit using Pulse (I also discussed this a bit in the context of reliability at https://github.com/klinker-apps/messenger-issues/issues/101#issuecomment-373424858).

kerem commented

2026-02-26 01:31:19 +03:00

Author

Owner

@jberkel commented on GitHub (Apr 14, 2018):

I think SMS will still be around for a while, there are still many markets with low smartphone usage/bad internet. it'd be nice if Android offered a common storage protocol for all the different messaging solutions, then SMS Backup+ could just hook into that.

re: restoring, this should probably be addressed seriously in a future release. I think there's definitely a way to make it faster and more reliable (even if it fails with a temp error it could pick up where it stopped on the next run)

anyway, thanks for your help, it allows me to focus more on the development part 👍

@jberkel commented on GitHub (Apr 14, 2018): I think SMS will still be around for a while, there are still many markets with low smartphone usage/bad internet. it'd be nice if Android offered a common storage protocol for all the different messaging solutions, then SMS Backup+ could just hook into that. re: restoring, this should probably be addressed seriously in a future release. I think there's definitely a way to make it faster and more reliable (even if it fails with a temp error it could pick up where it stopped on the next run) anyway, thanks for your help, it allows me to focus more on the development part 👍

kerem commented

2026-02-26 01:31:20 +03:00

Author

Owner

@kurahaupo commented on GitHub (Jan 3, 2020):

As I indicated in #985, I'm also helping out where I can.
Lately I've been adding new labels where there's commonality between issues; let me know if this is helpful. (I figure the text of a label can be changed, so they're merely my own suggestions.)

I've also added a few technical feature requests that should help fulfil various user functionality requests.

@kurahaupo commented on GitHub (Jan 3, 2020): As I indicated in #985, I'm also helping out where I can. Lately I've been adding new labels where there's commonality between issues; let me know if this is helpful. (I figure the text of a label can be changed, so they're merely my own suggestions.) I've also added a few technical feature requests that should help fulfil various user functionality requests.