In the interest of helping this discussion along, let me change this from an open ended comment to a specific proposal.
What if we require a PR for every commit? No cherry picking. This would mean that a change might need three or four, or possibly even five PRs, one for each affected branch. The primary benefit is we fully commit to the GitHub way of managing workflow. We can still do JIRAs but they become independent of commit work. (They kind of are already, if you think about it. A change is reviewed for master and then backported, and the backports may or may not see review themselves, and may or may not be done on a different JIRA, there's no consistency there.) This would have the additional benefit of raising the visibility of changes going into maintenance branches. Rather than have a committer possibly doing cherry picks in the background there would be a nominal PR review cycle for everything. Overall it raises our workload, though. Even if a committer or PMC opts to ignore the additional PRs raised for backports there is still some cognitive work needed to sort through the list of PRs or emails about same and decide what to ignore. Would also require branch maintainers to be responsive to gitbox at-mentions, though. Probably would also require branch maintainers to drive the additional PRs for changes landing in their respective branch(es). What do you think? On Fri, Dec 7, 2018 at 9:23 AM Andrew Purtell <[email protected]> wrote: > 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. > > > > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
