Hello all,
I would add to Vince’s points that CI is still not so stable that rebasing is always trivial: on a couple of my recent PR’s both the Playwright tests and the browser test suite have produced false positives that have disappeared with a
rerun. More rebases means more opportunities for such false positives, which are a minor annoyance in a committer’s PR’s, since we can easily rerun CI, but a greater annoyance in a contributor’s PR’s, since a committer has to rerun them, and the contributor
may not understand why they’ve occurred, let alone reoccurred.
Best,
Colin
From: theia-dev <theia-dev-bounces@xxxxxxxxxxx> On Behalf Of
Vincent Fugnitto via theia-dev
Sent: Monday, March 27, 2023 6:55 AM
To: theia developer discussions <theia-dev@xxxxxxxxxxx>
Cc: Vincent Fugnitto <vincent.fugnitto@xxxxxxxxxxxx>
Subject: Re: [theia-dev] New feature enabled for CI: Require branches to be up to date before merging
I believe there are some significant drawbacks with the new "require branches to be up to date before merging" option during CI as it makes working in open-source (especially for non-committers)
more difficult.
-
The process adds friction for non-committers when instead we want to encourage them to contribute
-
There does not seem to be the automatic "update" button during CI from forks unless explicity set by each contributor
-
Asking contributors to constantly rebase since master was updated adds friction, and it becomes increasingly difficult to get something merged from different time zones (ex: China) as master is a moving target
I think we may want to revisit the option, especially since we haven't really encountered an issue with an outdated pull-request often, and the drawbacks I've mentioned.
I can add a note in the dev meeting if needed.
I had not thought about that, but it does make sense. In fact, I do see it happening on your PR about enabling context isolation, that originates from your fork, where
presumably you have not granted permission for maintainers to edit.
That, coupled with the need for one of our project committers (user with write access to our repo) to push the "Approve and run" CI button, post-branch-update, might make
for a bit of back-and-forth between us and external (non-committer) contributors.
One thing we could do to mitigate this is to update our PR template to encourage external contributors to grant us "allow edits from maintainers" on their PR? Maybe we
can do this after the trial period of one month is over?
I guess you need write access to the branch to be merged in order to see the "Update branch" button, right? Because it's your own branch or the contributor checked "allow
edits from maintainers"?
|