2026-08-10 BTR Meeting notes (Verawood retro)

Verawood recap

@Maria Grimaldi

• Recap of the cycle before retro discussion: shipped Verawood.1 then moved to weekly point releases;

• 39 release-testing issues reported (May 25 - Jul 30), 44 PRs backported after branch cut, 28% of reported issues also flagged as blockers, 23 closed / 16 open as of Aug 10.

• Timeline slipped 5 weeks past the original June 23 target, mainly due to a broken testing sandbox (May 11-22) and testing completion lagging (~26% by June 15).

• The flexible cadence and earlier readiness checks adopted from the Ulmo retro held up;

• large features landing close to the cut, sandbox instability, and pending backport reviews carried over unresolved.

See How did the release go?

Retro: stop, start, continue

@Maria Grimaldi & team

See Retro: stop, start, continue and the retro board: VERAWOOD RELEASE CYCLEPreview

Two major discussions happened, documented in the next items.

Release cadence discussion

@Jenna Makowski & team

Jenna's "set dates around feature timelines" sticky note became the meeting's main open discussion (~25 minutes), no firm decision reached. Two Willow features are already at risk against the October 23 target, on top of Verawood's carried-over backlog and the next RBAC phase landing in the same window, which is what's forcing the conversation now.

Six proposals came up:

1. Plan dates around feature timelines *(Jenna)* - let the release date follow when major features are actually ready, though Jenna flagged this needs more data on operator upgrade behavior first, and that her real interest is aligning intentional major releases with external events (e.g. a conference), not open-ended slipping.

2. Decide per-feature at a hard checkpoint *(Farhaan)* - pick a checkpoint during planning to decide whether each feature ships this release or slips, unless it's the only thing driving the release.

3. Split fixed releases from feature releases *(Feanil)* - keep a fixed cadence, let feature delivery happen separately; Sarina's pushback: worth confirming operators would adopt releases with nothing new in them.

4. Lighter testing for non-feature releases *(Jenna)* - apply a lighter process to enhancement/fix/security-only releases; Feanil ties this to the bigger point that testing cost is the real driver behind expensive releases.

5. Point releases stay maintenance-only, majors carry features *(Farhaan)* - so operators only jump to a major version when they want that release's features; grounded in his hosting experience that operators mostly deploy point releases for security patches or active bugs. Currently what we’re trying to do with minor releases.

6. Treat breaking-changes-only releases as effectively major *(Feanil)* - questions whether a point release with breaking changes is really still a point release; flagged as his personal, not settled, view.

Where there's agreement: nobody wants to slow releases down for its own sake, everyone agrees more data is needed (real operator upgrade behavior, point-release adoption frequency), and testing cost/automation underlies most of the proposals. @Sarina Canelake, @Chelsea Rathbun, and @Jenna Makowski discussed (not yet committed) running a short survey of major operators (e.g. edunext, Edly) on upgrade behavior and release-date expectations.

@Peter Pinch added historical context: the current schedule dates back to a time with no schedule at all, and the twice-yearly cadence was originally tied to the academic calendar, which matters less to the community now.

RBAC testing retro

• Could this cycle's RBAC issues have been caught earlier than end-to-end testing?

• Gap identified: no sandbox consistently tracked master with everything integrated into the platform.

• Next phase target: integrate and test everything in that sandbox, plus use PR sandboxes for end-to-end integration testing. Which edge cases needed testing also became clear too late relative to the cut, a learning point for next cycle.

• Open question underneath: how many issues were genuinely e2e-only vs. gaps that unit/CI coverage should have caught. Some permission issues couldn't be reproduced at the unit level, suggesting the permission system may be under-covered there regardless of new RBAC work.

• Others (e.g. a Studio course-creation bug) are the kind only e2e testing catches, reinforcing the need for more live/e2e infrastructure. Sorting each issue into "unit-testing miss" vs. "e2e-only" would help prioritize which e2e tests to build first, see follow-up actions.

@Farhaan Bukhsh

Write up a short document/Slack message describing the Willow experiment (mark at-risk features with their own readiness date; backport breaking changes/improvements into regular Ulmo/Verawood point releases, coordinated with the Deprecation and Maintenance working groups), so the group can discuss and decide on it.

@Chelsea Rathbun

Take point on improving how test priorities are communicated to the community during the next release's testing period.

@Maria Grimaldi

Go back through this cycle's reported release-testing issues and determine which were unit-testing misses vs. genuine end-to-end-only edge cases, to guide where to invest in test coverage next.

@Maria Grimaldi

Write up the discussion and turn it into action items, then share a follow-up message with next steps for Willow.

@Jenna Makowski

Continue narrowing the timeline for the two at-risk Willow features; expects a clearer picture within 1-2 weeks.

@Sarina Canelake , @Chelsea Rathbun , @Jenna Makowski

Considering a survey of major Open edX operators (e.g. edunext, Edly) on release-cadence expectations and upgrade behavior - not yet committed, but discussed as a likely next step for the release-cadence question