David Kastrup wrote:
So I lean towards the following process modeled upon our old one:
No push to master except by automation. Staging is unprotected and gets
scheduled runners. People ultimately rebase and push there once they
get Patch-push status. Default branch can be master as long as we make
sure that one cannot push there: that way you never rebase on ephemeral
commits.
When James gives Patch-push status (which he hopefully does supported by
a script), at the same time any merge request pointed at master gets
changed to point at staging. So if you are "Patch-push", the "Push"
button starts working.
That means as long as staging isn't stuck (and we should make sure that
the scheduled pipelines do not pick up the same commit more than once to
avoid wasting our minutes), you can rebase on master when you want (or
not). One initial pipeline run should be require to get into "Review"
state. Rebasing puts you back to "Patch-new" (which for trivial stuff
you may choose to hand-replace with "Patch-review" at the danger of
later getting staging borked).
It would be nice that if staging has tested as being borked, we could
temporarily disable pushes to staging: that will keep the patches and
merge requests requiring redoing limited. We got out along without that
previously but if the automation is good for that, that would be great.
At any rate, this scheme naively does not seem to require stuff
impossible to do with Gitlab, at least for the basic parts of operation.
And it would mean that you can usually rebase and forget without waiting
for pipeline completions. And you get the liberty of bypassing most CI
and rebases if you don't want to.
I may be wrong about the possibility to do this with a reasonable amount
of effort: I don't want to get hopes up unnecessarily.
That sounds reasonable, but alas, rather complicated. What about the
other option, that is, switching to a non-linear history, with merge
commits?
My fear is that we get back to a complex and non-standard development
process. The simple fact of having two branches to look at is already
a source of confusion for the unexperimented (for instance, merge requests
will target master at the time you create them, but that will change for
staging automatically). From the information I could gather, one of the
main incentives for moving to GitLab was making it easier to contribute
by standardizing the workflow. GitLab does everything we want, the only
blocker is the fast-forward merge strategy, if I understand well (please
correct me in case I don't). I would happily live with merge commits if
that facilitates development for everyone.
Plus, a non-linear history would skip all the rebases, which are creating
unnecessary noise within the merge requests. And it would be a lot less
work to set up, given that Jonas expressed to be fed-up.
And, I very much understand the difficulties you're facing in real life,
the nerve-wracking French lockdown, the thorny situation artists
face, etc. So if LilyPond is an additional cause of frustration for you,
maybe it could do you good to set it aside for a while and focus
on your current problems. At least, that's what I did.