Re: [platform-dev] Turn on protected branches?

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

> Of course rebasing a green PR may lead to a red main branch in bad circumstances

At the moment the Platform CI rebuilds every open PR against current master on every master commit. That build is done with a merge commit of PR and master, so even the 1 in 1000 cases you are seeing probably goes away too.

The above may change once there start being a lot of open PRs and the CI is forever rebuilding PRs. 

For example https://github.com/eclipse-platform/eclipse.platform.resources/pull/4 has been rebuilt 14 times https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-4/ even though there has only been a single commit on that PR.

HTH in the decision making.

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

On Thu, 31 Mar 2022 at 12:34, Michael Keppler <Michael.Keppler@xxxxxx> wrote:

Am 29.03.2022 um 21:38 schrieb Gayan Perera:
>
> It would be really good if we can enforce ff-merge only to avoid hard
> to trace history graphs.
>
That's one of the things that makes one-time-contributors abandon their
change after initial submission quite often, to my experience. They
can't do anything than rebasing, and rebasing again, and so on, every
time that a project committer submitted one of their own changes first.
And every time the hope on someone really merging the change goes down a
bit more.

Just get used to rebasing as default merge strategy instead. That also
gives a linear history, doesn't require contributors to repeatedly do
work that doesn't create value and has in fact been already used on the
eclipse gerrit by some projects without any issues.

Of course rebasing a green PR may lead to a red main branch in bad
circumstances, so chances of breaking the main branch are a bit higher
than with ff only. In our company we use rebase on merge and we see it
between 1 and 2 times per 10000 commits, that the target branch is
broken because of this (where "ff only" would have detected a broken
build). I would claim that there are _way_ more broken builds because of
other uncontrolled changes (some permission changed on some eclipse
server, an upgrade of some tool that everyone thought is unrelated,
...), so that this tiny additional chance of a red main branch doesn't
really matter. But it improves the ability to just merge _everything_
that has been reviewed and tested, instead of exactly 1 out of the same
set of changes, and then someone having to rebase and to wait 20 minutes
for building until the next 1 change can be merged.

Ciao, Michael

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev