public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: "Desimone, Nathaniel L" <nathaniel.l.desimone@intel.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>,
	"bret.barkelew@microsoft.com" <bret.barkelew@microsoft.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"spbrogan@outlook.com" <spbrogan@outlook.com>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process
Date: Wed, 20 May 2020 19:05:45 +0200	[thread overview]
Message-ID: <2d42ff42-e028-96aa-6397-284f730d5dab@redhat.com> (raw)
In-Reply-To: <1DF48A10-F119-4FAE-9963-E95A48D82648@intel.com>

On 05/19/20 23:02, Desimone, Nathaniel L wrote:

> Of course, there may be other patch series that would be logical to
> squash, especially if the author has not been careful to maintain
> bisectability. For example, I think of some patch series went a
> little overboard and could have been done in maybe 1-2 patches
> instead of 8-10. I would be happy to compromise with you and say that
> squashes can be done in circumstances where both the maintainer and
> the author agree to it.

Important distinction:

(a) "squashing patches" is a 100% valid operation that some situations
fully justifiedly call for. Maintainers may ask for it, and contributors
may use it with or without being asked, if the situation calls for it.

(b) "squashing patches *on merge*" is intolerable.

The difference is whether there is a final human review for the
*post-squash* state before the merge occurs.

The valid case is when the contributor squashes some patches, resubmits
the review/pull request, the reviewer approves the *complete* work
(after performing another review, which may of course be incremental in
nature), and then the series is merged exactly as it was submitted.

The invalid case (squash on merge) is when the reviewer checks /
approves the series when it still contains incremental fixes as
broken-out patches, then squashes some patches (in the worst case: all
patches into one), and then merges the result. In this (invalid) case,
the complete work, in its final state (in the way it's going to land in
the git history) has not been reviewed by either submitter or reviewer,
incrementally or otherwise. This is why squash on merge is intolerable:
it places a sequence of commits into the git history that has never been
reviewed *verbatim* by either submitter or reviewer. It's a "blind
merge", to make up another term for illustration

Squashing is a 100% valid tool, I use it all the time. Squash-on-merge
is a catastrophic process failure.

Thanks
Laszlo


  parent reply	other threads:[~2020-05-20 17:05 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  7:21 [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process Nate DeSimone
2020-05-19  8:39 ` Laszlo Ersek
2020-05-19 18:02   ` Nate DeSimone
2020-05-19 16:54 ` Sean
2020-05-19 18:02   ` Nate DeSimone
2020-05-19 19:34     ` Bret Barkelew
2020-05-19 19:59       ` Nate DeSimone
2020-05-19 20:10         ` Bret Barkelew
2020-05-19 21:02           ` Nate DeSimone
2020-05-19 21:07             ` Bret Barkelew
2020-05-20 17:05             ` Laszlo Ersek [this message]
2020-05-20 17:21               ` Sean
2020-05-22  1:56                 ` Andrew Fish
2020-05-20 21:53           ` Laszlo Ersek
2020-05-22  5:31             ` [EXTERNAL] " Bret Barkelew
2020-05-19 21:22       ` Laszlo Ersek
2020-05-19 21:35         ` Nate DeSimone
2020-05-19 21:38           ` Bret Barkelew
2020-05-19 20:41   ` Laszlo Ersek
2020-05-19 22:25     ` Sean
2020-05-21 13:30       ` Laszlo Ersek
2020-05-21 17:53         ` Sean
2020-05-22  2:59         ` Andrew Fish
2020-05-22  5:48           ` [EXTERNAL] " Bret Barkelew
2020-05-22 17:20             ` Laszlo Ersek
2020-05-25  4:09             ` [EXTERNAL] " Andrew Fish
2020-05-25 18:10               ` Laszlo Ersek
2020-05-25 18:28                 ` Andrew Fish
2020-05-26 11:17                   ` Laszlo Ersek
2020-05-26 14:39                     ` Samer El-Haj-Mahmoud
2020-05-26 16:13                       ` Bret Barkelew
2020-05-27  1:52                   ` Bret Barkelew
2020-05-27  9:27                     ` Tomas Pilar (tpilar)
2020-05-27 12:12                     ` Laszlo Ersek
2020-05-27 22:07                       ` Rebecca Cran
2020-05-27 17:39                         ` Andrew Fish
2020-05-27 17:45                         ` Bret Barkelew
2020-05-28  6:57                           ` Bret Barkelew
2020-05-27 18:32                         ` Laszlo Ersek
  -- strict thread matches above, loose matches on Subject: below --
2020-05-09  2:59 Michael D Kinney
2020-05-09  4:22 ` Ni, Ray
2020-05-11 19:47   ` [edk2-devel] " Laszlo Ersek
2020-05-09 18:24 ` Rebecca Cran
2020-05-10 21:29   ` Michael D Kinney
2020-05-10 21:43     ` Rebecca Cran
2020-05-11  1:37       ` Michael D Kinney
2020-05-11 20:05         ` Laszlo Ersek
2020-05-11 20:00       ` Laszlo Ersek
2020-05-11 19:50     ` Laszlo Ersek
2020-05-11 19:39 ` Laszlo Ersek
2020-05-11 20:09   ` [EXTERNAL] " Bret Barkelew
2020-05-11 20:43     ` Michael D Kinney
2020-05-14 21:26       ` Bret Barkelew
2020-05-15  1:19         ` Michael D Kinney
2020-05-15  4:49           ` Bret Barkelew
2020-05-15  9:07             ` Laszlo Ersek
2020-05-15 15:43               ` Bret Barkelew
2020-05-18 11:48                 ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d42ff42-e028-96aa-6397-284f730d5dab@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox