cameel
commented
1 year ago I think that we could solve it even better. Instead of creating sync PRs for tags and daily sync PRs at the same time, the bot should keep creating sync PRs only for the next tag and switch to daily PRs for develop only when all tags are translated.
So, say a team starts its translation by cloning the upstream repo somewhere between 0.8.13 and 0.8.14 while the current version is 0.8.17:
- Initially the bot should create a single sync PR for 0.8.14. If it's closed without merging the bot should recreate it but not create any other PRs.
- Once the sync PR is merged the history will include 0.8.14 from the Solidity repo. Bot should see that and create a sync PR for 0.8.15.
- When 0.8.17 is translated, bot should switch to creating daily sync PRs to sync with
develop.
This would also have a nice effect of reducing the daily spam of sync PRs for teams that have not caught up and are ignoring them anyway.
Some translator teams are targeting specific tagged versions of the compiler (for example the Turkish team wants to translate and tag 0.8.15 before moving on to translating any further changes). In this use case the team is not interested in receiving PRs each time something changes in the main repo but will still be interested in a PR covering all the changes since the last release once a new one is tagged.
And overall, even if the team is fully caught up and translating all incoming changes, getting a specific version translated can be a problem if we set the PR interval to multiple days (and we might want to do that if it turns out that daily is too often). For example if we set it to a PR per week, and a compiler release happens in the middle of the week, there will be no PR containing only changes up to the release. There will be one covering the whole week, possibly containing bits from both versions.
For this reason the bot should: