/
Merge Guidelines for Coding Core Contributors

Merge Guidelines for Coding Core Contributors

Core contributors: Please consider these guidelines in conjunction with those listed in CC reviews and ownership.

TL;DR

Core Contributors:

  • Join the channel #cc-risky-changesand post about risky upcoming changes.

  • Merge at any time once you’ve met a repository’s review requirements.

  • Use defensive CI/CD techniques such as feature toggles, where applicable.

Background: Early Deployers

A handful of site operators deploy code very close to the tip of the default branches (master or main) of Open edX's backend service and frontend application repositories. This helps them rapidly iterate on features and fixes. It also helps the community by ensuring that the latest Open edX code is battle-tested in a large-scale environments. These are our early deployers. The known early deployers are:

Organization

Open edX Site(s) using early deployment

Points of contact

Organization

Open edX Site(s) using early deployment

Points of contact

2U

courses.edx.org

edge.edx.org

@Jeremy Ristau

@Robert Raposa

MIT Office of Digital Learning

mitxonline.mit.edu

@Peter Pinch

@Tobias Macey

This means that breaking changes and bugs will impact these site operators much sooner than site operators using the more-stable 6-month community releases. This is a valuable service provided by early deployers, so we encourage CCs to communicate as much information as possible about changes they believe carry risk and use defensive CI/CD techniques as appropriate. This will help early deployers minimize production incidents and stay close to the tip of master.

General requirements

Merges to master must using defensive CI/CD techniques such as feature toggles, where applicable.

Communications

Core Contributors, join these channels:

  • #cc-risky-changes

If you are working on a change that you realize might be risky to deploy or might have some deployment complexity, it is important to announce/link to it in #cc-risky-changes as soon as you come to that realization. You can merge changes to any repositories as soon as you have met the repository’s review requirements.

  • If you are unsure, err on posting an [inform] post in #cc-risky-changes.

  • If you have any questions about when and if to post, simply ask in #cc-risky-changes.

If you want even more exposure to your change, you have the option of posting to Discuss and tagging the https://discuss.openedx.org/g/early-deployers group.

Merging and Reverts

What can I merge?

You can merge whenever you want to once you have met that repository’s review requirements.

What if something breaks?

If your PR breaks tests on master, any core contributor with access may revert it.

If your PR breaks the community-supported development environment (currently Tutor Main), and the breakage is clearly not due to a bug in the development environment itself, then any core contributor with access may revert it.

If your PR causes a problem in an early deployer’s deployment pipeline or production environment, then the early deployer will triage the situation and try to gauge the nature of the breakage:

  1. If the breakage is clearly due to a bug in your PR… then the early deployer may immediately revert your PR, as long as they provide logs or other supporting information in the revert PR’s description or in a follow-up comment. The onus is on you (the contributor) to reintroduce a fixed version of your PR.

  2. If the breakage is clearly due to a operational or configuration detail of this particular early deployer, (i.e., there is no breakage to Open edX’s supported API contracts)… then your PR ideally should not be reverted. The early deployer must do their best to mitigate the issue in their own environment without resorting to reverting.

  3. If it is ambiguous whether 1 or 2 is the case… then the early deployer may proceed as if it is situation 1 (i.e., there is a bug in your PR), but they must work then with you (the contributor) to help identify the underyling nature of the issue. If it turns out that it is actually situation 2 (i.e., the problem is an artifact of the early deployer’s environment), then ideally you can just re-merge your original PR.