Avi Drissman | f54d7ca | 2021-05-12 14:57:48 | [diff] [blame] | 1 | # Chromium Flag Ownership |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 2 | |
| 3 | ellyjones@ / avi@ |
| 4 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 5 | This document explains flag ownership in Chromium, and gives some principles and |
| 6 | best practices. |
Avi Drissman | f54d7ca | 2021-05-12 14:57:48 | [diff] [blame] | 7 | |
| 8 | See also [Chromium Flag Expiry](flag_expiry.md). |
| 9 | |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 10 | [TOC] |
| 11 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 12 | ## What Is Flag Ownership? |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 13 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 14 | Every entry in chrome://flags is required to have at least one listed owner, |
| 15 | which can be: |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 16 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 17 | * A single person |
| 18 | * A mailing list |
| 19 | * A reference to an OWNERS file |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 20 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 21 | The owners of a flag serve as points of contact for it, and are notified when |
| 22 | it expires. |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 23 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 24 | ## Who Should Be An Owner? |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 25 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 26 | In general, it's a good idea to include: |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 27 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 28 | * The one or two SWEs who know the most about the flag and why it exists |
| 29 | * An appropriate mailing list for the team that owns it, so that expirations are |
| 30 | not missed, or |
| 31 | * An owners file that contains all the members of the owning team, again so that |
| 32 | expirations are not missed. |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 33 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 34 | Three important notes about listing owners: |
| 35 | |
| 36 | * Any entry that is just a bare word (like "username") is treated as being |
| 37 | @chromium.org; by far the most common mistake is to write "username" when |
| 38 | "[email protected]" is meant. This is not a problem if you have both |
| 39 | chromium.org and google.com addresses. |
| 40 | * The flag ownership database is *public*, so if your team's name is supposed to |
| 41 | be secret, don't list it; in that situation, it's better to create a new list |
| 42 | with a less revealing name and have it forward to your team's list. |
| 43 | * Every listed owner must be able to receive email from an *unprivileged* |
| 44 | google.com account, so please don't list your team's private list that |
| 45 | requires joining to post or similar - your flag expiration email will bounce. |
| 46 | If your team's list needs to remain closed to posting, you should instead make |
| 47 | a separate list that allows open posting, or list an OWNERS file full of |
| 48 | individuals. |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 49 | |
| 50 | ## I Don't Want My Flag To Expire! |
| 51 | |
| 52 | Some flags do not control UI features, but rather are commonly-used debugging |
Corentin Wallez | e660b15 | 2020-07-15 16:07:54 | [diff] [blame] | 53 | controls, such as `ignore-gpu-blocklist`. For these flags, see the instructions |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 54 | at the head of `flag-metadata.json`. Please be very judicious about |
| 55 | never-expiring flags, since they represent ongoing engineering, test and support |
| 56 | burden. The flags team will probably only approve your non-expiring flag if: |
| 57 | |
| 58 | - You regularly ask users or developers to change its value for |
| 59 | debugging/support purposes |
| 60 | - You have been doing so for at least six months |
| 61 | - You don't plan to stop doing so any time soon |
| 62 | |
| 63 | If you have a non-expiring flag, the flags team requires a comment in the json |
| 64 | file as to the rationale that it be non-expiring. A quick sentence or two will |
Avi Drissman | f54d7ca | 2021-05-12 14:57:48 | [diff] [blame] | 65 | be fine. (Yes, we are aware that, technically, JSON files can't have comments. |
| 66 | Don't worry about it.) You'll also need to add your flag to the permitted list |
| 67 | in |
| 68 | [`//chrome/browser/flag-never-expire-list.json`](../chrome/browser/flag-never-expire-list.json) |
Elly Fong-Jones | 9296136 | 2019-03-11 15:32:19 | [diff] [blame] | 69 | which will require approval from the flags team. |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 70 | |
| 71 | ## What Should My Expiry Be? |
| 72 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 73 | A good rule of thumb is that your flag should expire at least one milestone |
| 74 | after you expect your feature to have launched to stable. In other words, if |
| 75 | your feature will be 100% enabled on Stable in M74, your flag should be marked |
| 76 | as expiring in M75 or later. However, you can freely leave yourself lots of |
| 77 | slack - the purpose of expiration is to ensure that obsolete flags eventually |
| 78 | get cleaned up, but whether that takes one milestone or five for any given flag |
| 79 | is not a big deal. It is also very easy to adjust the expiration milestone later |
| 80 | if you need to. |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 81 | |
Elly Fong-Jones | cdb3a5c | 2023-01-05 20:56:15 | [diff] [blame] | 82 | One practice is to always set your expirations to the next "round" milestone |
| 83 | after you expect to launch, so that your team can batch flag cleanup work - for |
| 84 | example, if your feature is planned to go out in M101, you might set the |
| 85 | expiration to M105, and then your team might schedule a flag cleanup for the 105 |
| 86 | branch time. |
Avi Drissman | 465e778e | 2019-02-07 23:41:00 | [diff] [blame] | 87 | |
| 88 | ## I Have Other Questions |
| 89 | |
| 90 | Please get in touch with |
| 91 | [`[email protected]`](https://groups.google.com/a/chromium.org/forum/#!forum/flags-dev). |
| 92 | If you feel like you need to have a Google-internal discussion for some reason, |
| 93 | there's also |
| 94 | [`chrome-flags@`](https://groups.google.com/a/google.com/forum/#!forum/chrome-flags). |
Avi Drissman | f54d7ca | 2021-05-12 14:57:48 | [diff] [blame] | 95 | |
| 96 | ## Relevant Source Files |
| 97 | |
| 98 | * [`//chrome/browser/about_flags.cc`](../chrome/browser/about_flags.cc) |
| 99 | * [`//chrome/browser/flag-metadata.json`](../chrome/browser/flag-metadata.json) |
| 100 | * [`//chrome/browser/flag-never-expire-list.json`](../chrome/browser/flag-never-expire-list.json) |
| 101 | * [`//chrome/browser/expired_flags_list.h`](../chrome/browser/expired_flags_list.h) |
Avi Drissman | dbaa3cd | 2021-05-13 16:07:33 | [diff] [blame] | 102 | * [`//ios/chrome/browser/flags/about_flags.mm`](../ios/chrome/browser/flags/about_flags.mm) |
Avi Drissman | f54d7ca | 2021-05-12 14:57:48 | [diff] [blame] | 103 | * [`//tools/flags/generate_expired_list.py`](../tools/flags/generate_expired_list.py) |
| 104 | * [`//tools/flags/generate_unexpire_flags.py`](../tools/flags/generate_unexpire_flags.py) |