Policy on Feature flags

[SuperJappie08]

I was wondering if there is a policy on feature flags with regards to the following things:

• Where can people find these flags? (so more people can test them)
• Where is the function explained? (What does changing this switch intend to do)
• What is the plan/timeline for a feature flag? (How are we preventing the collective 'forgetting' of a feature flag, resulting in it existing for years)

I want to know these things because I would be willing to run some experimental flags as a beta tester.
But I'm missing some context on what things might break and what should change.

The current feature flags I could find were:

• restore_build_isolation, which is related to builddependency pollution.
• drop_test_deps, which is related to test ordering.

[cottsay]

Hi, thanks for your interest!

Where can people find these flags?

Flags can be defined in any colcon extension, so the flags available at any time depend on the extensions installed. That said, centralizing a list on https://colcon.readthedocs.io probably makes sense.

Where is the function explained?

The pull request that adds each flag should probably have a decent description of the functionality. As said though, it would be nice to include this in a centralized list somewhere for the important flags.

What is the plan/timeline for a feature flag?

I don't think we'll be able to develop a one-size-fits-all policy for timeboxing the flags, especially when the reason for hiding an incomplete feature is often that there is more work to be done.

---

Those two flags are the only two that I've added, yes. We're discussing adding two more flags in the near future:

1. A flag to tighten the build dependency graph even further for isolated builds, making indirect "build export" dependencies unavailable where possible.
2. A flag to use the standards-based Python packaging toolchain instead of the setuptools-only one.

If there are improvements you'd like to see here, regarding documentation or otherwise, please consider getting involved with the project. Most of the developers are present at OSRF Infrastructure PMC meetings on Mondays, and we're also on Zulip. As always, pull requests and reviews on pull requests are welcome and encouraged.