Discussion: switch to merge workflow

[VannTen]

Currently, we are using the "squash" method from tide (the merger component of Prow)

This pose some problems:

• Dependents PRs (PRs with a starting point being the tip of another PR, useful when something require a lot of refactoring / loosely related changes, see Migrate DNS manifests to kubernetes.core.k8s #10701 for instance ) have to be "manually" rebased on top of master once the prerequisite PR is merged.
  ( By manually, I mean that git rebase is usually able to detect "already applied commits", but squashing breaks that.)
• Squash throw away history granularity. When doing a git blame (which I do fairly often these days when trying to refactor stuff which seems strange), I have often unrelated changes mashed together, which make it harder to understand the point of the line I'm looking for.
• Commits messages matters, or at least they should. Squashing create a bad incentive to just not care about them, they'll be squashed together anyway and can't explain the change associated with them. (Since you can't associate a message with a precise set of changes)

Cons of a merge workflow:
The only arguments I usually here are:

• squash make for a nice (hear: linear) history -> besides the aesthetic, I don't see what practical benefits this brings
• noise commits (aka typo fixes, etc) -> this is the job of the PR author to rebase its branch before merging, if necessary, arranging commits in logical chunks. (and of the reviewers to not accept badly written history)

Soliciting advice from @MrFreezeex @mzaian @floryut @yankay (and anyone else)

[nicolas-goudry]

I’ll allow myself to give my thoughts about this.

The only thing that I’m concerned about is that doing this would give more work to reviewers, since I’m pretty sure that most authors won’t bother cleaning their commits before opening a PR. Maybe this is acceptable, I just wanted to point it out.

Other than that concern, I strongly agree with all your points and think that this is a very good idea.

[VannTen]

We should actually be doing this now, but we don't exactly bother, and I think the squash workflow is one of the reasons.
The work is not in vain though, because otherwise you have to do more work when refactoring/understanding the code/etc (and I think there is often an intersection between people doing refactors and reviewers)

[champtar]

FYI anyone you can already use

/label tide/merge-method-rebase

[VannTen]

I didn't know about that, thanks ! (Still think that we should switch the default, but that certainly helps)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[nicolas-goudry]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[VannTen]

/remove-lifecycle stale /lifecycle frozen