Tracking issues for to-be-mirrored features

[ddbeck]

When a feature lands in one browser engine, it often lands in browsers that use that engine at various times. While we can accommodate future releases in BCD's schema (with beta and nightly annotations), we don't have a way of tracking an unversioned next release. To help deal with this better, we should document a process to track features which are impacted by this.

Process proposal

I am sure I can write better instructions for a docs PR, but here's my imagined process for your consideration.

To borrow from #6551, suppose a feature is landing in Chromium M86. It'll show up in Chrome 86, Chrome for Android 86, and WebView 86. It will also show up in Opera and Samsung Internet in some future version, but we don't have a version numbers for those browsers yet. We need to make a log of features affected by this. Here's what we should to do keep and clear that log:

1. When a new engine version is first added to BCD, open a new issue with a title of the form "Mirror Project Number features", where Project is the name of the originating project and Number is the version number we'd mirror from. For example, when the PR is opened to add Chrome 86, then at the same time an issue should be opened called Mirror Chromium 86 features.

   The issue itself needs two key things:

   • an ## Applicable features section for a checklist of dotted feature identifiers (e.g., api.SomeAPI.someMethod)
   • an assignee or a call for an assignee (i.e., someone who's committing to following up when browsers get applicable releases)

2. For each version 86 feature added or modified, add the feature to the list of dotted feature identifiers and annotate with a link to the PR(s) that created those changes.

3. When a browser has a corresponding release (e.g., Opera has a release which matches or subsumes Chromium 86), the assignee opens a PR that runs the mirroring script for the features listed in the issue. Reviewers or PR authors would be advised to update the tracking issue when a /browsers PR is merged (we could change the PR template to note this or add perhaps add some GitHub automation to remind us).

4. This process continues until there are no more browsers with unrecorded Chromium 86 releases. When all of the features in the list have been mirrored to all of the browsers, the issue is closed.

---

I'm sure I'm missing something here or there are some details we can bikeshed ("Mirror Blink 86 features"?). Let me know what you think!

[sideshowbarker]

Thanks for writing this up. The proposal here all sounds reasonable to me — and I have no improvements to suggest. So 👍

[jpmedley]

Sounds good.

[foolip]

This sounds good to me. I would however like to hear from @AdaRoseCannon, since I closed #6602 as not very useful. If we tracked what needs to be mirrored for future releases of Samsung Internet, would this really be useful?

A more lightweight approach which I think matches @AdaRoseCannon's process better might be to run the mirror script for each browser release and manage all the changes that suggests.

One concern I'd like to air around this is that the more automation we place around these things, the more likely it is that actual differences between browsers that have been vetted by humans will be overwritten in batch updates. I don't know if that's been discussed extensively in some other issue.

[ddbeck]

Now that we've got some distance from this proposal, I don't think this is going to work. It's quite a lot of manual bookkeeping and that doesn't feel sustainable.

Instead, I think we should put more effort and attention into the diff tool, #6862. It might be a lot easier to deal with as a bit of automation that, for example, periodically generates an issue that lists features recently changed for Chrome, but didn't change for Opera. We've got a mirroring tool too—we could conceivably generate PRs, someday.

[ddbeck]

To give this an actual next action: unless anyone has an objection or better idea, I'm inclined to close this issue.

[sideshowbarker]

To give this an actual next action: unless anyone has an objection or better idea, I'm inclined to close this issue.

I have no objection, nor any better idea to suggest (other than agreeing with what you already suggested about focusing more effort and attention on the diff tool instead)