(In reply to Aki Sasaki [:aki] (he/him) (UTC-7) from comment #8) > I'm playing with the latest patch. In CI, we have a few options: > > 1. generate the changeset and possibly notify. A human will need to land the patch. > 2. generate the changeset and submit it to Phabricator, flagging a review group for review. A human will need to review and Lando. > 3. generate the changeset and push it to the strings repo without review. > > Do we want to rule any of the above out? > (1) seems easiest to add to CI, but it can be prone to human error or bad actors. It could be an intermediate stopgap, however. (2) seems preferable in terms of security and human verification, but still requires someone to do something. (3) is completely hands-off, but we lose the ability to catch issues before they land, and we have to open the repo up to automated writes without review. I'd rule out 2, with my preference for 3 over 1. The goal of this code is to push changes to a `quarantine` repository (that we should move out of a personal space, and probably place it under /l10n) https://hg.mozilla.org/users/axel_mozilla.com/gecko-strings-quarantine/ This repository is not hooked up to anything, it just receives updates. This content is periodically (and manually) pushed to [gecko-strings](https://hg.mozilla.org/l10n/gecko-strings), at which point it's officially exposed for localization via Pontoon, and used in other automation (e.g. linting, fluent migration testing, etc.). There's a risk that the content will have issues, and we need to fix it somehow (stop automation, potentially nuke the content), but that doesn't justify the extra work required for 2 in terms of reviews. There will be at least one patch every day, and how do we deal with multiple patches accumulating over 3/4 days? The latter would be an issue also for 1. Nuking the content of quarantine was the only option for the old code, since the references in each commit were needed to replay history. That wouldn't be the case here: we could stop automation, push a manual commit fix, and things would still work.
Bug 1659691 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Aki Sasaki [:aki] (he/him) (UTC-7) from comment #8) > I'm playing with the latest patch. In CI, we have a few options: > > 1. generate the changeset and possibly notify. A human will need to land the patch. > 2. generate the changeset and submit it to Phabricator, flagging a review group for review. A human will need to review and Lando. > 3. generate the changeset and push it to the strings repo without review. > > Do we want to rule any of the above out? > (1) seems easiest to add to CI, but it can be prone to human error or bad actors. It could be an intermediate stopgap, however. (2) seems preferable in terms of security and human verification, but still requires someone to do something. (3) is completely hands-off, but we lose the ability to catch issues before they land, and we have to open the repo up to automated writes without review. I'd rule out 2, with my preference for 3 over 1. The goal of this code is to push changes to a `quarantine` repository (that we should move out of a personal space, and probably place under /l10n) https://hg.mozilla.org/users/axel_mozilla.com/gecko-strings-quarantine/ This repository is not hooked up to anything, it just receives updates. This content is periodically (and manually) pushed to [gecko-strings](https://hg.mozilla.org/l10n/gecko-strings), at which point it's officially exposed for localization via Pontoon, and used in other automation (e.g. linting, fluent migration testing, etc.). There's a risk that the content will have issues, and we need to fix it somehow (stop automation, potentially nuke the content), but that doesn't justify the extra work required for 2 in terms of reviews. There will be at least one patch every day, and how do we deal with multiple patches accumulating over 3/4 days? The latter would be an issue also for 1. Nuking the content of quarantine was the only option for the old code, since the references in each commit were needed to replay history. That wouldn't be the case here: we could stop automation, push a manual commit fix, and things would still work.