We also need to discuss and document how to target specific code lines. You 
can't fix a branch-1 issue where the code is different in branch-2 and up by 
opening a PR against master (assuming this is the default branch). It seems 
obvious but is not. Occasionally a fix is relevant for all branches but needs 
three or four distinct patches due to differences among the code lines. In that 
situation do we require a PR for each distinct change? One for master, 
branch-2, and branch-1, and again for branch-1.2, per recent example? 

Squash merging is a must I think. Otherwise cherry picking changes from the 
branch that received the PR changes to other branches is unnecessary difficult 
and frankly life is too short. It is difficult enough to participate in this 
project already just given the challenges of having three major code lines and 
several more releasing branches. 

Or maybe we won't do cherry picks and instead do it by PR for every branch / 
commit?

Need to sort all of this out and provide clarity now before a switch over. 

> On Dec 7, 2018, at 9:03 AM, Sean Busbey <[email protected]> wrote:
> 
> Hi folks!
> 
> Per the email from infra "[NOTICE] Mandatory relocation of Apache git 
> repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe ) it looks 
> like the future of interacting directly with PRs is coming sooner rather than 
> later.
> 
> I think we should move to gitbox ASAP rather than wait for the crunch. If we 
> hit a rough spot we're more likely to get some help when things aren't busy. 
> Maybe we wait until our open RCs close so that folks that need to tag those 
> releases don't need to update their workflow first?
> 
> Presuming everyone still agrees that we get value out of JIRA, I think we 
> need update our committer guidelines to expressly remind folks to check on 
> things like commit messages before merging PRs, as well as to ensure folks 
> use the "squash and merge" option to keep the git history less complicated. 
> Probably a good time to add text about the importance of backporting, since 
> there isn't a github UI for doing that.
> 
> 
> 
> 

Reply via email to