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
>

Reply via email to