Skip to content

Conversation

AlexanderLanin
Copy link
Member

Review Timeline:

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

@Copilot Copilot AI review requested due to automatic review settings September 25, 2025 20:14
Copy link

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

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

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

Copy link

@thilo-schmitt thilo-schmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants