You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suggestion of @Xavier-Do after transifex was mean again (kept pushing to 15.0 and 16.0 yesterday and thus cancelled essentially every staging): for the safer stuff like transifex, rather than require a full blown PR the mergebot could have a queue of commits to cherrypick, which it would simply shift into stagings. Two options were considered:
shift in / add those commits when creating the staging, the advantage is that those commits would be tested, the drawback is that it's hard to decide what would happen if the staging fails, whether because of a false positive or because the commit happens to be broken (which has happened once or twice w/ transifex but is really uncommon all things considered)
shift in after the staging, just before pushing to the reference branch, this reduces the delay if there's already a staging going on, but only if the staging is successful
or a combination of the two: just before / after checking if there's stuff to stage but separately, shift all the commits into the upstream branch directly, then do the staging
The latter seems like it combines all the advantages of the other two, and limits the drawbacks, and can furthermore allow immediate updates by cancelling the current staging for the branch (thus limiting the risks of conflicts). Eventually it could also allow suppressing the runbot build because e.g. it's not super useful to create a runbot build just because we merged translations.
TBD: how to tell the mergebot about those commits? Backend UI? API? Other?
A patch version should be supported for convenience / scripting, even though it will require working copies / worktrees after we managed to expunge them from the mergebot (neither git am nor git apply support applying patches to git trees, sadly).
The text was updated successfully, but these errors were encountered:
Unstaged changes can be useful or necessary for some tasks
e.g. absolute emergency (where even faking the state of a staging is
not really desirable, if that's even possible anymore), or changes
which are so broad they're difficult to stage (e.g. t10s updates).
Add a new object which serves as a queue for patch to direct-apply,
with support for either text patches (udiff style out of git show or
format-patch) or commits to cherry-pick. In the former case, the part
of the show / format-patch before the diff itself is used for the
commit metadata (author, committer, dates, message) whereas for the
commit version the commit itself is reused as-is.
Applied patches are simply disabled for traceability.
Fixes#926
Suggestion of @Xavier-Do after transifex was mean again (kept pushing to 15.0 and 16.0 yesterday and thus cancelled essentially every staging): for the safer stuff like transifex, rather than require a full blown PR the mergebot could have a queue of commits to cherrypick, which it would simply shift into stagings. Two options were considered:
The latter seems like it combines all the advantages of the other two, and limits the drawbacks, and can furthermore allow immediate updates by cancelling the current staging for the branch (thus limiting the risks of conflicts). Eventually it could also allow suppressing the runbot build because e.g. it's not super useful to create a runbot build just because we merged translations.
TBD: how to tell the mergebot about those commits? Backend UI? API? Other?
/cc @d-fence @mart-e @beledouxdenis
A patch version should be supported for convenience / scripting, even though it will require working copies / worktrees after we managed to expunge them from the mergebot (neither
git am
norgit apply
support applying patches to git trees, sadly).The text was updated successfully, but these errors were encountered: