Maybe we can even request Twitter verification badges for the Accounts
We've been working on this for all of our accounts, but they require official (read: government) documents of ownership. Since the Foundation is still being applied for, we have none of these.
I believe you. I've been checking it. I've tried to reproduce the problem and I've asked people who have complained about it before to do the same.
With that, I must say that "Please check it, it's a bug" makes me a little upset. It's mostly due to my own failure to reproduce the problem. I encourage you to file a bug rather than complain about issues on the forum. That gives us a better place to talk about it than a thread like this where lots of people are giving input. Also, you said the issue started occurring a couple of weeks ago? Did you mention it then?
For relevant log files, let's start with the standard ones at Contribute to UBports - Bug Reporting. Please follow the instructions there to file a bug. Some more relevant information... Is the device plugged in when the alarm is missed? What is your "missed alarm time" set to in Clock settings? Does the notification you missed the alarm appear after that time? Does the alarm always fail to ring, or only sometimes? Do you use your device heavily before the alarm fails to ring? There's a lot of information that is potentially relevant that we just don't have here.
I understand this issue is upsetting to you. I'm sorry I haven't been able to reproduce it. Please help me by following the normal process to file a bug report so we can get more opinions.
If you would like to implement these things, I fully encourage you to.
While you are seeing the same behavior, the semantics are different. When Ubuntu Touch runs out of memory, it will kill an app and retain a screenshot of it in the app switcher. The app is not crashing, but it does need to handle this situation better. You may want to file a bug on morph-browser since it does not restore open windows when it is killed due to low memory.
zram may help a little, but really the problem is that the system and apps are using too much memory, and you may be expecting a bit too much of your device. I've put in a PR to re-enable zram on the E5, but it will not be merged until after the OTA-6 release.
@Hsabun, volunteer developers will post their progress on their own terms. Asking for updates may be seen as impolite. Please have patience and we will get there eventually. :)
@htc_tattoo, we'll need more info than that to reproduce the problem. Which device are you using? How and when are the alarms set? Do they repeat? What is the position of each setting on the edit page?
Yes, that log has exactly what I expected at line 125:
Nov 28 17:02:32 ubuntu-phablet kernel: [10756.588033]Killing 'unity8' (2558), adj 10,
Nov 28 17:02:32 ubuntu-phablet kernel: [10756.588038] to free 113312kB on behalf of 'Thread (pooled)' (15633) because
Nov 28 17:02:32 ubuntu-phablet kernel: [10756.588043] cache 16288kB is below limit 16384kB for oom_score_adj 6
Nov 28 17:02:32 ubuntu-phablet kernel: [10756.588048] Free memory is -2764kB above reserved [gfp(0x200da)]
This is definitely a memory problem which manifests heavily on devices with 1GB of RAM.
You're discussing context-based computing, in a way. Maybe you'd like to expand your thoughts in the Design section?
As we near the OTA-6 release, I would like to gather what I believe are the most important points from this post:
stable is well-tested, which we do not have. Some things which would translate into more release confidence include:
I think that bringing up the edge channel as a place to do a large migrations out-of-band with the normal release cadence is going to have a huge impact on how quickly we can release in the future. Previously, @mariogrip's work on bringing us to upstream Libhybris would have had to wait until after OTA-6 lands, and then it would have delayed OTA-7 until we had proper confidence in it. With edge, we can have people help us test these huge changes with the ability to roll back and without disrupting current users.
To respond to my earlier hindsight: OTA-6 was not (yet :P ) taken away by TDS. We did not hit the original deadline set, but we will still be within our 6-8 week cycle when it releases. This includes our testing and release admin stage, which we are currently in. All of this while I'm not sweating bullets from pushing a release on ourselves before we're sure we're ready.
We have ended up in "Gotta release slower" in this cycle without a doubt. I hope to make the improvements we've identified here so "gotta release fast" can become a reality. I also hope to be able to take our release management up so that we hit 2-4 weeks development, 2 weeks testing. This means we'll get faster releases, but we still won't hit fast releases. :P
Important note for anyone interested in contributing to... basically anything I've said here: I'll be holding an OTA-7 development meeting at the start of the cycle where we'll discuss how we want to improve during the OTA-7 cycle and taking bugs from the tracker for the release. Only assigned tickets will be added to this milestone, so if you have a pet bug that you want fixed now is the time to get involved to help fix it! Subscribe to this GitLab issue for more information as the day draws nearer.