Going back to T's original point, I'd go as far as asking the following:
Once the PR is issued, do NOT squash until asked to do so.
The reason for it is that I just had a great experience with Percival on new
JMS support. There were 6+ follow ups. Joe only needed to review what we
agreed/argued,
Sounds good to here as well.
Given the increasing number of contributions, which predominantly seem to
arrive via GitHub PR, I also created NIFI-1615 [1] a little while ago to
make a GitHub PR template [1]. Would like to distill the contributor guide
down into a few easy steps for folks to check
As I was reviewing a pull request, i realized that it actually was a bit
more mental effort in this instance to review a squashed and rebased set of
commits than if it was if I could just review the changes in a commit. Does
anyone object to me adding in the contributors guide something to the
exte
+1 here as well
My apologies Tony
Sent from my iPhone
> On Mar 17, 2016, at 21:42, Joe Witt wrote:
>
> +1
>
>> On Thu, Mar 17, 2016 at 9:37 PM, Tony Kurc wrote:
>> As I was reviewing a pull request, i realized that it actually was a bit
>> more mental effort in this instance to review a squas
Aldrin,
Very cool
On Mar 17, 2016 10:21 PM, "Aldrin Piri" wrote:
> Sounds good to here as well.
>
> Given the increasing number of contributions, which predominantly seem to
> arrive via GitHub PR, I also created NIFI-1615 [1] a little while ago to
> make a GitHub PR template [1]. Would like to
+1 Yes please!
Sent from my iPhone
> On Mar 17, 2016, at 9:38 PM, Tony Kurc wrote:
>
> As I was reviewing a pull request, i realized that it actually was a bit
> more mental effort in this instance to review a squashed and rebased set of
> commits than if it was if I could just review the chang
+1
On Thu, Mar 17, 2016 at 9:37 PM, Tony Kurc wrote:
> As I was reviewing a pull request, i realized that it actually was a bit
> more mental effort in this instance to review a squashed and rebased set of
> commits than if it was if I could just review the changes in a commit. Does
> anyone obje
Matt Burgess and I were having this conversation last night as well. I prefer
to see the incremental steps of atomic units of work (i.e. commits) in a
thread, but understand some people prefer to review a single squashed commit
for a PR. In a feature branch, for example, I would prefer a way to
