From: Thomas Walker Lynch Date: Tue, 10 Mar 2026 08:02:44 +0000 (+0000) Subject: . X-Git-Url: https://git.reasoningtechnology.com/%5B%5E?a=commitdiff_plain;h=b1c09778b728bf58690b9118e118ed0cc45220c5;p=Harmony . --- diff --git a/document/temp.html b/document/temp.html deleted file mode 100644 index ac7bd7a..0000000 --- a/document/temp.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - Product maintenance roles and workflow - - - - - - - - - - -

Maintenance structure

-

- Teams mentioned in this document: -

-
    -
  1. tester team
  2. -
  3. core developer team
  4. -
  5. triage team
  6. -
- -

- Team membership is a role a person takes on. Multiple people share a role. A single person takes on multiple roles. -

- -

- The tester team develops and maintains the regression suite, the reliability suite, and additional tests. -

- -

- The developer team writes the source code, compiles promotion candidates, and ports patches between branches. -

- -

- The triage team evaluates defects reported against active releases. The team includes a developer contact, the project manager, and the product manager. -

- -

Issue queues

-

- The project maintains two distinct issue queues: -

-
    -
  1. released product
  2. -
  3. core development
  4. -
- -

- There can be additional queues for multiple branches of development, and for experiments. -

- -

Core development queue

-

- This queue serves the core_developer_branch. The tester writes a test for every issue reported in this queue. This isolates the defect, proves the fix, and guards against future regressions. -

- -

Released product queue

-

- This queue tracks defects reported against deployed software across any major version. -

-

- 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. -

-

- 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. -

- -

Patching and backporting

-

- The product manager defines what constitutes a critical issue. Only critical issues receive patches on a release branch. -

-

- If approved, the release team applies the fix directly to the existing release_v<major> branch. The branch name remains static. The administrator advances the minor release number and tags the commit. -

-

- The developer then ports the fix to the core_developer_branch. This step is mandatory. It prevents the defect from resurrecting in future major releases. -

- -
- -