I am +1 about having patches submitted via PRs. IMHO, we should disable the Jira QA altogether, but have the tool upload the *.patch file to Jira for archiving purposes.
On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <r...@itevenworks.net> wrote: > On 6 November 2016 at 11:54, Flavio Junqueira <f...@apache.org> wrote: > > > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for > reviewing. > > > > The QA for pull requests should be working for pull requests agains > > master, but let's keep an eye and polish any rough edges that might still > > be there. > > > > With ZOOKEEPER-2624 in, there is one last major decision we need to make > > to wrap this up. The pull request QA currently do not make a jira patch > > available. This is intentional because making it patch available will > > trigger the original Jira QA, which will be confusing because we will > see a > > failure (I haven't tested, but I think that's what's going to happen). If > > we change the script to make the Jira patch available, then we need to > > either: > > > > 1- Disable the Jira QA altogether, which means that we will only have > pull > > request QA available > > 2- Make the Jira QA script spot that there is a pull request available > and > > not build it. > > > > I'm wondering if folks would be ok with only having patches submitted via > > pull requests or if we should continue to support the old Jira QA. > > > > I am +1 on only having patches submitted via PRs, it's simpler to only have > to support one method. Thanks Flavio for making this happen! > > > -rgs >
