Am Samstag, den 23.05.2020, 19:59 +0200 schrieb Jonas Hahnfeld: > Hi all, > > I've now made the necessary settings, merged the changes in > https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all > existing merge requests to target 'master', and deleted 'staging'. > I've not rebased the existing merge requests and there's no need to do > so if it's already in one of the later stages (you'll be forced on > submission). However remember that James won't get MRs with Patch::new > for manual regression testing unless it has passed automated tests. > > The new procedure to push / merge is as follows: > 0. The patch reaches Patch::push via the known countdown process. > 1. GitLab only allows fast-forward merges, so it forces you to rebase > your changes. Without conflicts, the UI will present a button for this. > Otherwise, or if you prefer doing so, you can always rebase locally and > force-push the branch. > 2. Updating the merge requests triggers the CI jobs to run. The UI will > have a new button "Merge when pipeline succeeds". You can click this at > your convenience and the system will handle the rest. Otherwise you can > wait yourself and click the "normal" button labeled "Merge" as before. > > > If multiple merge requests are rebased simultaneously, GitLab merges > the first one that finishes CI testing. The other merge is aborted, but > the CI pipeline continues to run AFAICT. So for saving resources, > please try to avoid it. We'll see if this "contention" turns out to be > a problem...
Pinging this to attention...
signature.asc
Description: This is a digitally signed message part
