(+Leif, +Andrew)

Sean,

On 05/19/20 18:54, Sean Brogan wrote:

Nate/Laszlo,

Regarding a squash merge workflow.  I agree it can be abused and we all
have seen terrible examples.  But a patch series that contains 500+ file
changes isn't really much better.  Just because it is broken into
multiple commits doesn't mean it is the right set of commits.

Anyway a squash merge workflow works amazingly well with and is
optimized for a web based review and PR processes.  It allows a user to
respond to changes, fix issues, learn thru the PR process, all while
keeping complete track of the progression.  Then once all "status"
checks and reviews are complete, it is squashed into a neat commit for
mainline, containing only the relevant data in the message.

So, the ask is that we don't exclude squash merge workflows.  Those
reviewing the PR can decide what is appropriate for the PR content
submitted.  Just as you would request changes to the contents (or
ordering) of a commit in a series, if the reviewers don't agree that the
PR contents should be in a single commit then obviously it shouldn't be
squashed to one.

Contributions like spelling fixes, typos, minor bug fixes, documentation
additions/fixes, etc all are great examples of PRs that can easily
leverage squash merges and this workflow significantly lowers the burden
of the contribution and review process.  This workflow is also are much
easier for casual or first time contributors.

I don't exactly know how we would enable this but I assume we could
leverage tags or make it clear in the PR description.  First step is to
get alignment that a squash merge workflow, while not appropriate for
all contributions, is not something to be excluded.

the scope for migrating the contribution & review workflows off the
mailing list and to github.com was set many months ago. That scope does
not include institutionalized changes to patch set structuring criteria.
The "git forge" evaluations that we had spent weeks/months on also
focused on how candidate systems would honor a patch series' structure;
i.e., how faithful the system would remain to the contributors' and
reviewers' shared intent, with a specific patch set.

Your proposal to "don't exclude squash merge workflows" is a trap. If we
tolerate that option -- which is obviously the sloppy, and hence more
convenient, option for some maintainers and some contributors, to the
detriment of the git history --, then almost every core maintainer will
use it as frequently as they can. In the long term, that will hurt many
consumers of the core code. It will limit the ability of people not
regularly dealing with a particular core module to file a fine-grained
bug report for that module, maybe even propose a fix. From the
regression analyst's side, if the bug report starts with "I have a
bisection log", that's already a good day. And your proposal would
destroy that option, because maintainers and people in general are
irrepairably lazy and undisciplined. We cannot post a community member
shoulder-by-shoulder with every core package reviewer/maintainer to
prevent the latter from approving a squash-on-merge, out of pure
laziness. I'm 100% sure the "option" to squash-on-merge would
*immediately* be abused for a lot more than just "typo fixes". There
isn't enough manpower to watch the watchers, so "no squash-on-merge"
needs to be a general rule.

I'm very sad that you're trying to wiggle such a crucial and intrusive
workflow change into the scope of this transition. Every time
squash-on-merge has come up over the years (regardless of this
transition), we've labeled it as one thing never to do, because it
destroys information (and/or even encourages not *creating* that
historical information in the first place, which is of course important
in reality).

Well, anyway, here's my feedback: if squash-on-merge is permitted in
edk2 or in basetools (or in any other external repository that's a hard
requirement for building edk2), that's a deal breaker for me, and I'll
hand in my resignation as a steward.

Maybe you'd consider that a win, I don't know -- but I couldn't remain a
steward with a straight face after failing to protect what I consider
one of the core values of open source / distributed development.

Thanks,
Laszlo