Content Cutoff Review for the September Maintenance Releases

Good afternoon, everyone. Today is the content cutoff for the Orion September build, so this meeting has a very specific outcome: by the end of it, I want a final, locked list of what goes into the build that we submit to carriers tomorrow. After that, I'd like a quick round on the other models, because several of them have moving parts this month.

Jiho and Sungmin from Product Security. We'll cover the security content.

Minji and Tom from SQE. We have the validation results for every item.

Jiwoo, Kernel and BSP. I'll cover the kernel fixes, including the USB cherry-pick.

Let's start with security, since it's the reason this build exists. Jiho?

All thirty-one platform fixes from Google are merged and verified. Of the seven vendor fixes, the two kernel fixes are merged, and four of the five Qorvix fixes arrived on schedule last week and are merged. The fifth is the critical GPU issue, which arrived as the interim fix on August 20th, exactly as Raj promised.

And it's validated. We ran the graphics regression suite and the top hundred apps from the twentieth to the twenty-fourth. No functional regressions. The frame rate drop in the three affected games is seven percent, slightly better than the eight percent Qorvix estimated. Nothing else changed measurably.

One thing I want to flag. When we merged one of the two kernel security fixes, it conflicted with the storage timeout patch from the fixed maintenance build. Both touch the same function in the storage error handler. Jiwoo and I resolved it together on Friday, and Tom reran the storage stress profile over the weekend. It's clean.

Good catch, and good follow-through. A conflict in that exact function is exactly what I'd worry about. So security content is complete, and we can declare the September patch level?

Yes. All thirty-eight September items are in. The release notes say 'security improvements to the graphics driver' and mention a possible minor performance change in some games, with no details about the vulnerability, as we agreed with Olivia's team. The detailed security page is drafted for publication on September 7th.

Now the bug fixes that are riding along. Let's go one by one. The camera recording hang?

Validated on August 17th. Error injection showed zero hangs in a thousand injections, the one-hour 4K recordings at thirty degrees passed twenty out of twenty, and the camera regression suite is clean. One positive surprise: when the link error occurs, the recording now stops cleanly and the file is fully playable. The framework camera team had already handled that path correctly; the driver hang was just preventing it from running.

That's very good news for users. The modem firmware for the Iberian handover issue?

The fully validated firmware arrived from Qorvix on August 14th. Pedro ran drive tests on the Lisbon to Porto line for three days with zero modem crashes, compared with four in three hours before. Our own regression is clean. And Lucia confirmed the carrier will review it in five working days, as promised.

And the USB use-after-free?

The upstream fix was validated over the weekend. On the rig, the KASAN group had zero reports in forty-eight hours, and the production configuration group had zero crashes, while the control group on the old build crashed twenty-two times in the same period. The cherry-pick matches the upstream commit exactly. It's merged and ready.

Ken from Qorvix also sent his timing analysis. Their controller completes outstanding requests about eight times faster than the reference timing after disconnect, which explains why Orion saw the crash so much more often. Nathan confirmed that's correct behavior, so no change is needed on their side.

Are there any late requests for the Orion September build? This is the last chance.

There's one. The framework team asked this morning to add a fix for a rare crash in the settings app when switching languages. It's a two-line change, reviewed, with unit tests. But it hasn't gone through any of our regression suites yet.

My recommendation is no. It's a low-severity crash that has existed for months, and it can wait for October. This build already carries a critical security fix, a GPU workaround, a camera fix, a modem firmware, and a USB fix. I want every item in it to have been tested properly.

I agree. Small and low-risk isn't the same as tested. Tom, please let the framework team know it's targeted for October, and thank them for asking rather than sneaking it in.

Will do. I'll also suggest they merge it into the October branch today, so it gets a full month of nightly testing before it ships. That way, by the time it reaches users, it will have been tested more thoroughly than anything we could do in the next twenty-four hours.

Then let me lock it. The Orion September build contains: the full September security patch set, including the interim GPU fix; the camera recording hang fix; the Iberian modem firmware; and the USB cherry-pick. Nothing else. SQE runs the final sanity pass tonight, and we submit to carriers tomorrow, with the expedited path for the three slowest carriers. Any objections?

None from Security.

None from SQE, assuming tonight's sanity pass is clean.

None from kernel. I'd only ask that the sanity pass includes a few hours on the USB rig and a short storage stress run, since those are the two areas where kernel code changed most this month. If either shows anything unusual, I'd rather know before the build goes to carriers than after.

That's easy to add. The rig is free tonight, and a four-hour storage run fits within the sanity window. I'll include both results in the morning report.

Before we move to the other models, let's agree on how the September build rolls out once carriers approve it. Given how many components changed, I don't want to go straight to everyone.

I'd propose a slower start than usual: half a percent for seventy-two hours, then five percent, then everyone over the following week. That matches the rule we proposed for security-related firmware after the Wi-Fi incident, and this build contains two firmware changes.

From Security's side, I'd like the first stage to start before the bulletin goes public on September 7th, if carrier approvals allow. The interim GPU fix closes a critical privilege escalation, and every day after publication without the fix increases the risk.

That works if open markets go first. Carriers that approve quickly will be in the first wave, and the three slow carriers will follow once their expedited review is done. Tom, what halt criteria do you want for this build?

Four signals: the overall crash rate, the storage panic signature, Wi-Fi disconnects per device, and graphics-related crashes, since that's the area the interim GPU fix touches. Any of them going outside its threshold pauses the rollout automatically.

I'd also watch the validity check warning from the storage fix. Since we resolved a merge conflict in that exact function, I want to confirm that the warning rate in the field stays the same as on the previous build.

Good. All five signals go on the dashboard. Tom, can you have it ready before the first carrier approval comes back?

Yes, most of it already exists from the previous rollout. I just need to add the graphics signal and set its threshold based on the last month of data.

While we're on the GPU topic, let's not forget the full fix. Raj committed to September 3rd for the version without the performance penalty. Is that still on track?

As of Raj's status note on Friday, yes. Their internal testing is going well, and he expects to deliver on the third. That gives us about two weeks before the October cutoff, which is plenty for validation.

When it arrives, I'd like to validate it on the same three games plus a wider set of graphics-heavy apps. The original fix broke a performance optimization, so the redesigned version touches more code. I want to be sure it doesn't introduce rendering problems somewhere we haven't looked.

Agreed. And we should make sure the October release notes mention that the performance change from September has been resolved. Users who noticed the drop deserve to hear that it's fixed.

Now a quick round on the other models. First, the fixed Orion maintenance update that's rolling out. Tom?

After the Wi-Fi configuration was applied, the one percent group was clean for twenty-four hours, so we resumed to ten percent on Saturday the twenty-second. Wi-Fi disconnects are within five percent of the pre-update baseline, storage signatures are zero, and the crash rate is normal. We plan to go to fifty percent tomorrow and a hundred percent on Friday.

Good. Orion Lite?

The Orion Lite hotfix went out on August 18th as planned. It included the three critical fixes, plus the touch charger mode change, which the release council approved as an exception after seeing the service cost numbers. Early data from Southeast Asia is encouraging: ghost touch events while charging are down about seventy percent. The September release, 1.4.0, is on track for its cutoff next week and will include Sensira's new touch firmware if it validates in time.

And the two new launches, Nova Tab and Pulse Watch?

Nova Tab launched on Friday with the Wi-Fi configuration applied from day one, and the new thermal threshold passed its worst-case test, so it shipped in the day-one update. Reviews mention good sustained performance, which is a relief. Pulse Watch's first monthly update has its cutoff on Friday; the Bluetooth reconnect policy is in dogfood and looks good so far.

Looking across all of these, one pattern stands out to me. Almost every major issue this month involved a vendor firmware or driver change interacting with something on our side: the storage firmware and the timeout, the Wi-Fi firmware and old routers, the touch firmware and chargers, the modem firmware and the network. Our process treats vendor firmware updates much more lightly than our own code.

I raised the same point in the storage review two weeks ago. A new firmware binary is a change, even if no line of our code moves. I'd like firmware updates to go through the same subsystem-tagged testing as code changes: a storage firmware triggers storage stress, a Wi-Fi firmware triggers the interoperability lab, and so on.

I agree, and I'll take it to the release council on Friday as a formal proposal, together with the rule for staged rollouts of security-related firmware. It's better to change the process now, while the examples are fresh, than after the next incident.

Before we close, let's look at the next few weeks, because September is going to be crowded. We have the Orion September rollout, the Orion Lite 1.4.0 cutoff, the Pulse Watch update on the eighth, the Orion Fold launch on the eighteenth, and the first Atlas BSP 1.0 drop on the eleventh. SQE, are you staffed for all of that?

Honestly, it's tight. The stress lab is booked solid through mid-September, mostly for Orion Fold. If anything unexpected comes up on Orion or Orion Lite, we'll have to borrow devices from Atlas pre-validation again, which delays their baseline testing.

One thing that would help is staggering the cutoffs. Right now, Orion Lite 1.4.0 and Pulse Watch both have their content cutoffs in the same week. If Orion Lite's cutoff moved two days later, we could spread the validation load more evenly.

I can do that. Orion Lite's release date has some slack, and two days won't affect the carrier submission. I'll move its cutoff to September 3rd and let the teams know today.

From the kernel side, the stable cadence proposal for Orion is on the agenda for the vendor sync on Sunday. If we agree to monthly stable merges, the first one would land in October, so it won't add to September's load. But I want to flag that it will add steady work from October onward.

From Security's perspective, that steady work is worth it. Every month we merge stable updates is a month we're not three months behind on fixes like the USB one.

Noted. I'll make sure the monthly calendar shows all of these milestones in one view, so every team can see the collisions before they happen.

Action items. Minji and Tom: final sanity pass on the Orion September build tonight, results by 9 a.m. Jiho: final check of the release notes wording against the embargo rules. Sungmin: confirm that the source release script uses neutral commit messages for the security fixes. Jiwoo: write a short note on the merge conflict resolution for the archive. Tom: continue the rollout to fifty percent tomorrow. And I'll submit to carriers tomorrow and prepare the firmware testing proposal for Friday.

I already checked the script last week, after Olivia's reminder. It rewrites the messages correctly. I'll double-check on tomorrow's actual source package before it's published.

Perfect. Thank you, everyone. This was one of the most complicated monthly builds we've had, and it came together cleanly. Our next review is Tuesday, September 1st, at 2 p.m. Korea time.