It was an announcement on our forum for our userbase to explain why the last update introduced major issues with lag, how that happened, that it wasn't specific to GrapheneOS and that we were highly prioritizing working on it. Our release fixing it was pushed out to our Alpha channel yesterday, reached Beta early today and is now in Stable. We had to make an announcement about this because it was heavily impacting perhaps 1/5 people and was noticeable by many more people once they were made aware of it even though they weren't heavily impacted. Many users were complaining about this after there had been several days for memory pressure to start getting triggered for a much higher proportion of users.
There were a small number of complaints prior to us moving the release introducing the issue to Stable. There were very important security updates in the updated firmware/driver code and we decided we needed to release it despite that. It took several days for most people's setups to build up enough memory usage to start triggering it. It started impacting a lot more people after a while and we realized it was a severe issue we had to address ourselves instead of waiting for Google to do it.
Google likely had the same reasoning for pushing it out to people to get many other issues including security bugs fixed despite a major known regression. We did not have time to avoid the situation in advance. We had to either delay driver/firmware security updates or ship it and then fix this afterwards. The problem is that it typically takes them at least around 4 to 6 weeks to ship a fix for even a critical issue. They've sometimes managed to do it in 3 weeks in extremely critical cases. It's unusual for them to move that quickly and it takes them longer to do kernel changes userspace ones. Once we figured out the issue was, it was quickly fixed and we started builds for a release in the same day.
It takes a long time for us to build a release for 21 different devices despite having build machines for it due to each having a specialized build with only what they used and their CPU architecture, etc. and we actually need 42 builds due to security preview releases. We plan to make incremental builds reliable enough to use those for production but it requires great care and potentially ongoing CI testing of reproducible builds to make sure incremental builds haven't regressed. If memory wasn't so expensive, we could buy a bunch of hardware to upgrade or replace our existing 4 local build machines for official releases.