Today if you add a link to a PR on the main repo to a JIRA ticket and put it in patch available status, yetus should properly recognize and use it for testing. The results should go to JIRA like normal.
I don't think it's gotten much testing in our setup. (And it wouldn't work on the operator tools or connectors repos because our precommit currently only knows about the main repo.) On Sat, Dec 8, 2018, 01:44 Peter Somogyi <[email protected] wrote: > 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 <[email protected]> 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 <[email protected]> > 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 <[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) > > > > 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 > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > > - A23, Crosstalk > > >
