Should `behind-pref` be a status flag? about bug-handling HOT 3 CLOSED

I'd suggest using a value like Nightly61, Beta60, Release59, rather than just Nightly, Beta, Release. The concatenated string serves two purpose: 1) version info and 2) which stabilization cycle for this version had the feature on/off.

from bug-handling.

Thanks for writing this up. A more fine-grained flag seems useful.

When would the release value get set? When the feature is planned to ship in release, or when a release with that feature active is actually released? Likewise for the esr flag: would we set esr when we intend for the next ESR to ship with the feature or would we change all bugs with the flag value set to release to esr when a new ESR is released? The latter option in both cases (and for beta, too, I suppose) would generate a flood of mostly-useless bugmail.

(I think there is value in having a separate designation for ESR; there are probably features that we may not want active in the ESR for whatever reason, even if those features are rare. But I'm unsure of how often that would actually occur.)

from bug-handling.

Thanks for your patience while I catch up with requests and comments.

If I understand @rkothari19's suggestion, then behind-pref becomes a release status flag with values:

• ---
• in-progress
• off
• release60
• beta61
• nightly62

then on merge day we would add

• release61
• beta62
• nightly63

and disable (but not delete) release60, beta61, and nightly62.

Then the leads for the feature would need to update the flags appropriately until the bug is closed.

and @froydnj suggests a similar arrangement for the ESR releases where we have a behind-pref-esr flag which would have the values

• ---
• off
• 52
• 60

And would only had values added and removed when there's a new ESR release.

I can create a PR to the policy for this and request y'all review of it.

from bug-handling.