Sounds good to me except squash merge at commit of PR shouldn’t be an option it should be required except for good reason (and I don’t know what that would be )
> On Dec 8, 2018, at 3:28 PM, Stack <[email protected]> wrote: > >> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey <[email protected]> wrote: >> >> The move to gitbox doesn't require us to only accept github PRs. Given >> the current rate of contributions via patches on JIRA vs GitHub PRs, I >> wouldn't want to push for that now. >> >> The change does make it easier for us to start encouraging PR >> submissions, because committers will be able to directly merge from >> the GitHub UI. >> >> I'd recommend we try to keep this as a small incremental change. That >> would mean: >> >> * committers ensure there's an associated JIRA for release note and >> precommit checks (that can be just by pinging the contributor to go >> make one) >> * backports are still handled by the committer if they're simple and >> the contributor if there's a problem. I think saying "open a new PR to >> backport to branch FOO" is perfectly reasonable since it's analogous >> to when we ask contributors to attach a branch specific patch. >> * committers ensure the pushed commit has a message that follows our >> current practice (which would mean looking out for the "helpful" >> subject wrapping) >> * Squash merge is an option when the committer goes to accept the PR. >> the contributor is free to either push additional commits or squash on >> their branch when working through reviews, I don't think we need to >> weigh in on how contributors choose which of those works best for >> them. >> >> That way we can also incrementally improve how well we handle PR >> submissions by better documenting expectations and building up >> additional tooling (e.g. having our precommit feedback go directly to >> the PR instead of being tied to a JIRA) >> > > This seems reasonable to me. Andrew's strawman would be too radical a > change. > Thanks, > S > > >>> On Fri, Dec 7, 2018 at 12:09 PM Stack <[email protected]> wrote: >>> >>>> On Fri, 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. >>>> >>> >>> >>> Sounds good. >>> >>> Use this thread to list what needs documentation? (Agree with the "Need >> to >>> sort all of this out and provide clarity now before a switch over." from >>> Andrew). >>> >>> What should the commit be like? Should be like now? What about that ugly >>> bleed that happens when the first line is too long and gets dumped into >> the >>> textbox below ... which then becomes the log IIRC. >>> >>> When do we do the squash merge? Is that the committer who does this after >>> rounds of review? >>> >>> I like Andrew's list. >>> >>> On the 'You can't fix a branch-1 issue where the code is different in >>> branch-2 and up by opening a PR against master', this is a prob. at least >>> with our current 'process'. We don't do a JIRA per push because it is >> just >>> a bunch of busy work. Do we have to do this now (any alternatives?) >>> >>> Thanks for starting this up Sean, >>> S >>
