Can we protect the GitHub branches from direct merges? That’s a repo-level setting and we may not be able to change it. It seems potentially dangerous for people to be able to merge their own changes especially if it only takes one successful reviewer. Other communities use mechanisms like Prow [1] for this kind of thing. I imagine it requires some infrastructure though.
[1] https://github.com/kubernetes/test-infra/tree/master/prow On Fri, Apr 5, 2019 at 7:04 PM 张铎(Duo Zhang) <[email protected]> wrote: > Yes, at least there should be a relevant JIRA issue. > > And on the retesting, we need to find a way to re-trigger the webhook. But > anyway, we can fall back to use the old pre commit way, just checkout the > branch and make a patch and upload it to the jira issue... > > I'm trying to make use of GitHub in the recent works. And yesterday, I > added Zheng Hu as a reviewer for the addendum of HBASE-22152, and he posted > a LGTM and then just merged the PR... In fact I just want him to approve > the PR, this is the correct way to '+1' on GitHub. So I think we need to > write something done in the tell committers how to make use of the GitHub > PR... > > > > Sean Busbey <[email protected]> 于2019年4月6日周六 上午9:43写道： > > > Excellent to see Duo! > > > > Do we have any guidelines for committers in the ref guide? I think we had > > previously discussed calling out that they should make sure there's a > JIRA > > for anything merged? > > > > Does retesting work from the github UI or is it like before where one > > resubmits the jenkins job? > > > > On 2019/04/04 06:15:39, 张铎(Duo Zhang) <[email protected]> wrote: > > > Please see here > > > > > > https://github.com/apache/hbase/pull/110 > > > > > > Still need to polish the jenkinsfile so we can keep the same experience > > > with the old hadoop QA, but anyway, it basically works. > > > > > > So I think it is time to set up our github based workflow. Need to > > discuss > > > how to work together with our jira. > > > > > > Thanks. > > > > > >
