[AlexanderLanin]

Review Timeline:

• PR-based discussion starts here and now
• Will be discussed and ideally accepted in the next infrastructure community meeting

[github-actions]

⚠️ Docs-as-Code version mismatch detected
Please check the CI build logs for details and align the documentation version with the Bazel dependency.

[Copilot]

Pull Request Overview

This PR introduces a new design decision document (DR-003-Infra) that extends the integration testing approach established in DR-002 to handle components that cannot participate in pre-merge CI. The document defines a tiered integration model to accommodate external components and internal components in transition while maintaining system-level integration feedback.

Key changes:

• Establishes three tiers of integration testing based on when feedback is provided relative to component changes
• Defines migration paths for internal components to achieve full CI compliance
• Outlines handling of breaking changes across different tier components

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[github-actions]

The created documentation from the pull request is available at: docu-html

[thilo-schmitt]

Thank you for the detailed proposal. I fully support the direction outlined in DR-002 regarding integration strategy — it’s a solid foundation for improving release reliability and minimizing friction. Strengthening release management through clear processes and early detection of integration issues is absolutely the right goal.

However, I’m not convinced that the classification introduced in DR-003 adds meaningful value toward that goal. While it attempts to describe how tightly components are integrated and tested, the practical implications of the tier system remain unclear. For example, what does it mean for a component to be Tier 2 or Tier 3 in terms of release readiness or accountability? Is there a policy that enforces these labels or defines consequences if integration fails?

Without a clear connection between the classification and actionable release decisions, it risks being purely descriptive. If we want this to be useful, we should at least require every component to declare its tier and define what that means in practice — e.g., Tier 1 is required for release, Tier 2/3 are optional but may be excluded if they cause issues.

In summary, while I support the intent to improve integration and release quality, I believe DR-003 needs stronger alignment with practical release management outcomes to be truly effective.

[github-actions]

This PR is stale because it has been open for 30 days with no activity. It will be closed in 10 days if no further activity occurs. #magic___^_^___line

[github-actions]

Auto-closing: no activity for 30 days. If this is still relevant, reopen or create a fresh PR.