sungwy opened a new issue, #444: URL: https://github.com/apache/airflow-steward/issues/444
### What should happen A single tracker (one security@ list, one private tracking repo) should be able to handle findings across a family of separate upstream repos, routing each finding to the right repo for scope detection, fix targeting, and release tracking. ### Why Some ASF projects are structured as a family of separate upstream repos that share a single security mailing list and operate as one team. Apache Iceberg, for example, spans Java, Python, Go, Rust, C++, and Terraform implementations as sub-projects in distinct repos. Today `scope_detection.labels` and a single `upstream_repo` assume one upstream per tracker, so the only ways to adopt Magpie for such a project are to run a separate tracker + mailing list per sub-project (real infra overhead for a team that operates as one), or to give each sub-project its own `project.md`. But with a shared issue list, an un-routed finding can quietly fall through the per-scope triage filters and get lost. We'd rather close the gap if a single multi-repo tracker is a direction you're open to. ### Which layer Project template (`projects/_template/`) ### Boundary conditions (optional) - A finding that matches no sub-project should still be visible, not silently dropped from scoped triage sweeps (today it lands as `needs triage` but is invisible to `triage scope:<label>`). - Backward compatibility: a project with no sub-projects declared should behave exactly as today, with upstream_repo as the single implicit sub-project. ### Out of scope (optional) The exceptional private-PR fallback ([Step 9](https://github.com/apache/airflow-steward/blob/main/docs/security/process.md#step-9--open-a-private-pr-exceptional-cases)), where the base branch is the tracker's mirror of the upstream. Multi-repo setup affects that path too, but it's a separate, lower-frequency follow-on we'd rather not fold into this discussion. ### References (optional) _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
