+++ /dev/null
-
-<!DOCTYPE html>
-<html lang="en">
- <head>
- <meta charset="UTF-8">
- <title>Product maintenance roles and workflow</title>
- <script src="setup.js"></script>
- <script>
- window.StyleRT.include('RT/theme');
- window.StyleRT.include('RT/layout/article_tech_ref');
- </script>
- </head>
- <body>
- <RT-article>
- <RT-title
- author="Thomas Walker Lynch"
- date="2026-03-10"
- title="Product maintenance roles and workflow">
- </RT-title>
-
- <RT-TOC level="1"></RT-TOC>
-
- <h1>Maintenance structure</h1>
- <p>
- Teams mentioned in this document:
- </p>
- <ol>
- <li>tester team</li>
- <li>core developer team</li>
- <li>triage team</li>
- </ol>
-
- <p>
- Team membership is a role a person takes on. Multiple people share a role. A single person takes on multiple roles.
- </p>
-
- <p>
- The tester team develops and maintains the <RT-term>regression suite</RT-term>, the <RT-term>reliability suite</RT-term>, and <RT-term>additional tests</RT-term>.
- </p>
-
- <p>
- The developer team writes the source code, compiles promotion candidates, and ports patches between branches.
- </p>
-
- <p>
- The triage team evaluates defects reported against active releases. The team includes a developer contact, the project manager, and the product manager.
- </p>
-
- <h1>Issue queues</h1>
- <p>
- The project maintains two distinct issue queues:
- </p>
- <ol>
- <li>released product</li>
- <li>core development</li>
- </ol>
-
- <p>
- There can be additional queues for multiple branches of development, and for experiments.
- </p>
-
- <h2>Core development queue</h2>
- <p>
- This queue serves the <RT-code>core_developer_branch</RT-code>. The <RT-term>tester</RT-term> writes a test for every issue reported in this queue. This isolates the defect, proves the fix, and guards against future regressions.
- </p>
-
- <h2>Released product queue</h2>
- <p>
- This queue tracks defects reported against deployed software across any major version.
- </p>
- <p>
- Deployed software must be a usable quality product for the customer, beyond that we favor addressing issues in new releases, and encourage customers who are having issues to upgrade. This approach is purely one of keeping the maintenance problem under control. Other business units should address the commercial implications.
- </p>
- <p>
- Thus the triage team reviews each release issue. All issues that affect the core_developer branch are placed on the core development queue. Critical issues are also placed on the released product queue. The core development team is responsible for the core development queue issues, while the triage component of the development team is responsible for the released product queue issues.
- </p>
-
- <h1>Patching and backporting</h1>
- <p>
- The product manager defines what constitutes a critical issue. Only critical issues receive patches on a release branch.
- </p>
- <p>
- If approved, the release team applies the fix directly to the existing <RT-code>release_v<major></RT-code> branch. The branch name remains static. The administrator advances the minor release number and tags the commit.
- </p>
- <p>
- The developer then ports the fix to the <RT-code>core_developer_branch</RT-code>. This step is mandatory. It prevents the defect from resurrecting in future major releases.
- </p>
-
- </RT-article>
- </body>
-</html>
projects / Harmony / commitdiff