Currently how the addendum will be added to PR??
Won’t be another PR?? Where build run again ??
On Thu, 3 Jun 2021 at 1:33 AM, Eric Badger
wrote:
> I'm of a similar opinion to most here. If the backport is clean, I think
> it's ok to do it with just the +1 on the original patch. However,
I'm of a similar opinion to most here. If the backport is clean, I think
it's ok to do it with just the +1 on the original patch. However, please
please please build the code on the target branch before backporting
Eric
On Wed, Jun 2, 2021 at 2:46 PM Ayush Saxena wrote:
> For trivial changes,
For trivial changes, like changes in import or conflicts due to line number or
other trivial stuff, I don’t think that is required. Unless the general logic
isn’t changing, we can go ahead, may be we can do a test run before merging, to
be on the safer side as and when required. :-)
-Ayush
>
It is okay to go ahead and backport as long as there are no major refactoring
necessary.Minor conflict fixes should be fine.-Eric
On Tuesday, June 1, 2021, 11:43:44 PM CDT, Wei-Chiu Chuang
wrote:
I'm curious about the GitHub PR conventions we use today... say I want to
backport a commit
I think it comes down to "do you think somebody else needs to review it?".
I do like to test before a cherrypick -at least of all the tests which
the patch changed, and for object store stuff a full test run is good due
diligence, but I think at least for me
cherrypick no merge issues: local
I think we usually merge backport without explicit +1 if the conflict is
trivial,
same as done on JIRA-only workflow
(on which we attached patch like HADOOP-xxx-branch-3.3.001.patch for
precommit check then commit it without explicit +1).
If committers want review since the change is not
I'm curious about the GitHub PR conventions we use today... say I want to
backport a commit from trunk to branch-3.3, and there's a small code
conflict so I push a PR against branch-3.3 using GitHub to go through the
precommit check.
Do I need explicit approval from another committer to merge the
