How should we verify pull requests in the new workflow? I wouldn't like to force contributors to create a PR and also attach the same patch file to Jira to have it tested. In case the plan is to create PR-based precommit I'd recommend to test run it on hbase-connectors or hbase-operator tools gitbox repositories.
On Sat, Dec 8, 2018 at 3:30 AM Sean Busbey <bus...@apache.org> wrote: > Yes I definitely agree. I think that'll take some committer practice > and I'll want to have a decent section in the ref guide to point folks > to. On the plus side, there's a step committers have to go through to > link their ASF ID to their GitHub profile before they can start > merging through the GitHub UI. So if we tell folks about how to do > that step at the same time as show them how to make sure they're > squash merging maybe we'll avoid some mistakes. > On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell <apurt...@apache.org> wrote: > > > > However you want to best phrase it, squash merging for commit is a must, > I > > think. Depending on the contributor's style there could be 1 or 10 > commits > > comprising the PR. Even more than one commit for a change encompassed by > a > > JIRA would make cherry picking between the branches unnecessarily > onerous. > > This is really the only thing I'd like to establish as very important. > > > > > > On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey <bus...@apache.org> 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) > > > On Fri, Dec 7, 2018 at 12:09 PM Stack <st...@duboce.net> wrote: > > > > > > > > On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey <bus...@apache.org> > 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 > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk >
