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 >
