Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
I'm totally +1 to this approach, even though I think script should be
modified to Storm's project style.
Like I said to dev@ mailing list, I have been doing reviewing and merging
pending pull requests for weeks and months, and it was painful enough to merge
and port back to each branches, even though I ignored cleaning up commits.
(Pain is amplified when tiny commit should be merged to all branches.) If I
want to clean up commits before merging it should be more painful. CHANGELOG is
subject to not in sync among branches, but we need to write it manually because
it's hard to filter merge commits to see the change list. (We could just rely
on JIRA issues for alternative.)
Regarding commits, I don't want to keep commits like 'kicking travis',
'address review comments', etc. which is not helpful at any chances. For my
last 2 years of development of Storm, I didn't utilize individual commit. If
something is wrong with recent merge, we rollback the merge, not individual
commit. Squashing commits is widely used strategy and already shows success
story to many big projects. Even Github provides the squash merge mode
(recently rebase mode too) in GUI.
If we want to merge in squashed commit, it should be done in merging
process, not reviewing process. For me, ideal review process should be
contributor-friendly. While we can't put efforts to only maintain Storm project
(by reviewing pull requests, etc.), contributors also can't. Once we create a
script which also squashes the commits, we don't need to make contributors
bothering with rebasing and squashing commits. If not, all individuals
including us should do it just after merger said 'please rebase and squash in
order to merge.', which is also bothering for mergers, too. Moreover, there's a
chance for contributors to be busy at the moment, and pull request goes stale.
Pull requests which need upmerging are the case.
I understand and agree the authorship issue, but we can treat it as
exceptional case. Many pull requests are authored by one.
Let's make merging phase as painless, or at least less painful thing.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
