Re: [DISCUSS] QA github pre-commit queue

[Patrick Hunt]

On Wed, Nov 9, 2016 at 6:46 PM, Flavio Junqueira  wrote:

>
> > On 09 Nov 2016, at 10:39, Patrick Hunt  wrote:
> >
> > What are the implications of moving away from JIRA patches? Any legal/IP?
> > Also PRs are through github.com, which is not infra owned by Apache.
>
> This is supported by infra:
>
> https://reference.apache.org/pmc/github
>
> > If
> > that service ever goes away we'll lose that information.
>
> Comments on the pull request are currently propagated to the corresponding
> jira. See for example ZOOKEEPER-1525.
>
> > What are other
> > projects doing in this regard?
>
> I'm aware of at least 3 projects: Spark, Kafka, and BookKeeper.
>
> >  Any impact on our workflows outside of
> > qabot? e.g. release other other activity tracking?
>
> Not that I'm aware of. The only difference if we make this change is that
> patch available would be set by our script and the script won't look for a
> patch in the jira.
>
>
Sounds reasonable - there are no downsides then?

Patrick


>
> >
> > Patrick
> >
> > On Tue, Nov 8, 2016 at 6:37 PM, Flavio P JUNQUEIRA 
> wrote:
> >
> >> I don't have any strong argument for keeping the Jira patches other than
> >> the fact that this is what we have been doing since the project was
> >> created. If there is anyone who do not want to use github in the
> community,
> >> please speak up.
> >>
> >> -Flavio
> >>
> >> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han  wrote:
> >>
> >>> +1 for disabling jira qa and only support pull request for code change
> >>> contributions. Besides making support easier this approach is also
> >> aligned
> >>> with what Spark and Kafka is doing, and being consistent across Apache
> >>> projects regarding how to use PR seems a good thing to do.
> >>>
> > have the tool upload the *.patch file to Jira for archiving purposes.
> >>> I think nothing will prevent a user submit a patch file to JIRA with
> our
> >>> script changes, so the functionality of archiving patches will still
> >> work.
> >>> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that
> do
> >>> not include patch file in JIRA for code contributions, so probably we'd
> >> do
> >>> this too for consistency purpose? Are there any benefit of archiving
> >>> patches given we prefer (or actually require) pull request instead of
> >>> patches?
> >>>
> >>> [1]
> >>> https://cwiki.apache.org/confluence/display/KAFKA/
> >>> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> >>> [2]
> >>> https://cwiki.apache.org/confluence/display/SPARK/
> Contributing+to+Spark#
> >>> ContributingtoSpark-PullRequest
> >>>
> >>> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <
> edward.ribe...@gmail.com
> >>>
> >>> wrote:
> >>>
>  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 
> >> 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
> >
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Cheers
> >>> Michael.
> >>>
> >>
>
>

Re: [DISCUSS] QA github pre-commit queue

[Flavio Junqueira]

> On 09 Nov 2016, at 10:39, Patrick Hunt  wrote:
> 
> What are the implications of moving away from JIRA patches? Any legal/IP?
> Also PRs are through github.com, which is not infra owned by Apache.

This is supported by infra:

https://reference.apache.org/pmc/github

> If
> that service ever goes away we'll lose that information.

Comments on the pull request are currently propagated to the corresponding 
jira. See for example ZOOKEEPER-1525.

> What are other
> projects doing in this regard?

I'm aware of at least 3 projects: Spark, Kafka, and BookKeeper.

>  Any impact on our workflows outside of
> qabot? e.g. release other other activity tracking?

Not that I'm aware of. The only difference if we make this change is that patch 
available would be set by our script and the script won't look for a patch in 
the jira.

-Flavio

> 
> Patrick
> 
> On Tue, Nov 8, 2016 at 6:37 PM, Flavio P JUNQUEIRA  wrote:
> 
>> I don't have any strong argument for keeping the Jira patches other than
>> the fact that this is what we have been doing since the project was
>> created. If there is anyone who do not want to use github in the community,
>> please speak up.
>> 
>> -Flavio
>> 
>> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han  wrote:
>> 
>>> +1 for disabling jira qa and only support pull request for code change
>>> contributions. Besides making support easier this approach is also
>> aligned
>>> with what Spark and Kafka is doing, and being consistent across Apache
>>> projects regarding how to use PR seems a good thing to do.
>>> 
> have the tool upload the *.patch file to Jira for archiving purposes.
>>> I think nothing will prevent a user submit a patch file to JIRA with our
>>> script changes, so the functionality of archiving patches will still
>> work.
>>> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
>>> not include patch file in JIRA for code contributions, so probably we'd
>> do
>>> this too for consistency purpose? Are there any benefit of archiving
>>> patches given we prefer (or actually require) pull request instead of
>>> patches?
>>> 
>>> [1]
>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
>>> [2]
>>> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#
>>> ContributingtoSpark-PullRequest
>>> 
>>> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro >> 
>>> wrote:
>>> 
 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 
>> 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
> 
 
>>> 
>>> 
>>> 
>>> --
>>> Cheers
>>> Michael.
>>> 
>> 

Re: [DISCUSS] QA github pre-commit queue

[Patrick Hunt]

What are the implications of moving away from JIRA patches? Any legal/IP?
Also PRs are through github.com, which is not infra owned by Apache. If
that service ever goes away we'll lose that information. What are other
projects doing in this regard?  Any impact on our workflows outside of
qabot? e.g. release other other activity tracking?

Patrick

On Tue, Nov 8, 2016 at 6:37 PM, Flavio P JUNQUEIRA  wrote:

> I don't have any strong argument for keeping the Jira patches other than
> the fact that this is what we have been doing since the project was
> created. If there is anyone who do not want to use github in the community,
> please speak up.
>
> -Flavio
>
> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han  wrote:
>
> > +1 for disabling jira qa and only support pull request for code change
> > contributions. Besides making support easier this approach is also
> aligned
> > with what Spark and Kafka is doing, and being consistent across Apache
> > projects regarding how to use PR seems a good thing to do.
> >
> > >> have the tool upload the *.patch file to Jira for archiving purposes.
> > I think nothing will prevent a user submit a patch file to JIRA with our
> > script changes, so the functionality of archiving patches will still
> work.
> > Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> > not include patch file in JIRA for code contributions, so probably we'd
> do
> > this too for consistency purpose? Are there any benefit of archiving
> > patches given we prefer (or actually require) pull request instead of
> > patches?
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/KAFKA/
> > Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> > [2]
> > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#
> > ContributingtoSpark-PullRequest
> >
> > On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro  >
> > wrote:
> >
> > > 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 
> 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
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>

Re: [DISCUSS] QA github pre-commit queue

[Flavio P JUNQUEIRA]

I don't have any strong argument for keeping the Jira patches other than
the fact that this is what we have been doing since the project was
created. If there is anyone who do not want to use github in the community,
please speak up.

-Flavio

On Mon, Nov 7, 2016 at 9:49 AM, Michael Han  wrote:

> +1 for disabling jira qa and only support pull request for code change
> contributions. Besides making support easier this approach is also aligned
> with what Spark and Kafka is doing, and being consistent across Apache
> projects regarding how to use PR seems a good thing to do.
>
> >> have the tool upload the *.patch file to Jira for archiving purposes.
> I think nothing will prevent a user submit a patch file to JIRA with our
> script changes, so the functionality of archiving patches will still work.
> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> not include patch file in JIRA for code contributions, so probably we'd do
> this too for consistency purpose? Are there any benefit of archiving
> patches given we prefer (or actually require) pull request instead of
> patches?
>
> [1]
> https://cwiki.apache.org/confluence/display/KAFKA/
> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> [2]
> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#
> ContributingtoSpark-PullRequest
>
> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro 
> wrote:
>
> > 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  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
> > >
> >
>
>
>
> --
> Cheers
> Michael.
>

Re: [DISCUSS] QA github pre-commit queue

[Flavio P JUNQUEIRA]

My bad, I made the build parameterized to see if I could trigger it
manually. I have disabled the parameters and should be back to normal now.

-Flavio

On Tue, Nov 8, 2016 at 4:00 PM, Michael Han  wrote:

> Git PR bot builds
>  have
> been failing after build 44. From the log it looks like for some reasons,
> variables like 'GIT_PR_NUMBER', 'GIT_PR_TITLE' etc were undefined. Is this
> a configuration issue of build bot?
>
> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han  wrote:
>
> > +1 for disabling jira qa and only support pull request for code change
> > contributions. Besides making support easier this approach is also
> aligned
> > with what Spark and Kafka is doing, and being consistent across Apache
> > projects regarding how to use PR seems a good thing to do.
> >
> > >> have the tool upload the *.patch file to Jira for archiving purposes.
> > I think nothing will prevent a user submit a patch file to JIRA with our
> > script changes, so the functionality of archiving patches will still
> work.
> > Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> > not include patch file in JIRA for code contributions, so probably we'd
> do
> > this too for consistency purpose? Are there any benefit of archiving
> > patches given we prefer (or actually require) pull request instead of
> > patches?
> >
> > [1] https://cwiki.apache.org/confluence/display/KAFKA/
> > Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> > [2] https://cwiki.apache.org/confluence/display/SPARK/
> > Contributing+to+Spark#ContributingtoSpark-PullRequest
> >
> > On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro  >
> > wrote:
> >
> >> 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  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
> >> >
> >>
> >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>
>
>
> --
> Cheers
> Michael.
>

Re: [DISCUSS] QA github pre-commit queue

[Michael Han]

Git PR bot builds
 have
been failing after build 44. From the log it looks like for some reasons,
variables like 'GIT_PR_NUMBER', 'GIT_PR_TITLE' etc were undefined. Is this
a configuration issue of build bot?

On Mon, Nov 7, 2016 at 9:49 AM, Michael Han  wrote:

> +1 for disabling jira qa and only support pull request for code change
> contributions. Besides making support easier this approach is also aligned
> with what Spark and Kafka is doing, and being consistent across Apache
> projects regarding how to use PR seems a good thing to do.
>
> >> have the tool upload the *.patch file to Jira for archiving purposes.
> I think nothing will prevent a user submit a patch file to JIRA with our
> script changes, so the functionality of archiving patches will still work.
> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> not include patch file in JIRA for code contributions, so probably we'd do
> this too for consistency purpose? Are there any benefit of archiving
> patches given we prefer (or actually require) pull request instead of
> patches?
>
> [1] https://cwiki.apache.org/confluence/display/KAFKA/
> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> [2] https://cwiki.apache.org/confluence/display/SPARK/
> Contributing+to+Spark#ContributingtoSpark-PullRequest
>
> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro 
> wrote:
>
>> 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  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
>> >
>>
>
>
>
> --
> Cheers
> Michael.
>



-- 
Cheers
Michael.

Re: [DISCUSS] QA github pre-commit queue

[Michael Han]

+1 for disabling jira qa and only support pull request for code change
contributions. Besides making support easier this approach is also aligned
with what Spark and Kafka is doing, and being consistent across Apache
projects regarding how to use PR seems a good thing to do.

>> have the tool upload the *.patch file to Jira for archiving purposes.
I think nothing will prevent a user submit a patch file to JIRA with our
script changes, so the functionality of archiving patches will still work.
Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
not include patch file in JIRA for code contributions, so probably we'd do
this too for consistency purpose? Are there any benefit of archiving
patches given we prefer (or actually require) pull request instead of
patches?

[1]
https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes#ContributingCodeChanges-PullRequest
[2]
https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-PullRequest

On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro 
wrote:

> 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  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
> >
>



-- 
Cheers
Michael.

Re: [DISCUSS] QA github pre-commit queue

[Edward Ribeiro]

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 
wrote:

> On 6 November 2016 at 11:54, Flavio Junqueira  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
>

Re: [DISCUSS] QA github pre-commit queue

[Raúl Gutiérrez Segalés]

On 6 November 2016 at 11:54, Flavio Junqueira  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

[DISCUSS] QA github pre-commit queue

[Flavio Junqueira]

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.

Thanks,
-Flavio

> On 02 Nov 2016, at 15:58, Flavio Junqueira  wrote:
> 
> Can I get reviews on ZOOKEEPER-2624/Pull Request #97, please? Once that gets 
> in, we will have pull request QA working.
> 
> Thanks,
> -Flavio
> 
>> On 31 Oct 2016, at 18:26, Edward Ribeiro  wrote:
>> 
>> My comments below:
>> 
>> On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira  wrote:
>> 
>>> 
>>> 
>> Feel free to contribute to my changes and suggest a different way in the
>>> jira. We can definitely work together on this, I just want to have this
>>> working soon.
>>> 
>> 
>> ​Ok. I don't want to slow down your current work in progress, so I will try
>> to see IF/WHAT I can contribute, but will let you know before hand.​ :)
>> 
>> 
>> 
>>> 
>>> The script is bash, not python.
>> 
>> 
>> ​Yup, in fact, I wrote the script with the intention of adding the option
>> of attaching the diff to the JIRA issue to zk-merge-pr.py tool. It woud be
>> for the sake of documeting the patch in the JIRA. Maybe I will create a new
>> issue proposing this once we have the other things sorted out, and only if
>> you guys think this is worth doing.
>> 
>> 
>> 
>>> It doesn't make it patch available mainly because if we make it patch
>>> available, then it will trigger the Jira QA, which will find no patch. It
>>> is a bit messy to trigger this second build, so I'm reluctant in doing it.
>>> I can see two options:
>>> 
>>> - Only do github pull requests, in which case "Patch Available" in our
>>> workflow means pull request available
>>> - Somehow detect that there is a pull request and no trigger the Jira QA
>>> 
>> 
>> ​IMHO, the the first option is less brittle and effective.
>> 
>> Edward
> 

Re: QA github pre-commit queue

[Flavio Junqueira]

Can I get reviews on ZOOKEEPER-2624/Pull Request #97, please? Once that gets 
in, we will have pull request QA working.

Thanks,
-Flavio

> On 31 Oct 2016, at 18:26, Edward Ribeiro  wrote:
> 
> My comments below:
> 
> On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira  wrote:
> 
>> 
>> 
> Feel free to contribute to my changes and suggest a different way in the
>> jira. We can definitely work together on this, I just want to have this
>> working soon.
>> 
> 
> ​Ok. I don't want to slow down your current work in progress, so I will try
> to see IF/WHAT I can contribute, but will let you know before hand.​ :)
> 
> 
> 
>> 
>> The script is bash, not python.
> 
> 
> ​Yup, in fact, I wrote the script with the intention of adding the option
> of attaching the diff to the JIRA issue to zk-merge-pr.py tool. It woud be
> for the sake of documeting the patch in the JIRA. Maybe I will create a new
> issue proposing this once we have the other things sorted out, and only if
> you guys think this is worth doing.
> 
> 
> 
>> It doesn't make it patch available mainly because if we make it patch
>> available, then it will trigger the Jira QA, which will find no patch. It
>> is a bit messy to trigger this second build, so I'm reluctant in doing it.
>> I can see two options:
>> 
>> - Only do github pull requests, in which case "Patch Available" in our
>> workflow means pull request available
>> - Somehow detect that there is a pull request and no trigger the Jira QA
>> 
> 
> ​IMHO, the the first option is less brittle and effective.
> 
> Edward

Re: QA github pre-commit queue

[Edward Ribeiro]

My comments below:

On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira  wrote:

>
>
Feel free to contribute to my changes and suggest a different way in the
> jira. We can definitely work together on this, I just want to have this
> working soon.
>

​Ok. I don't want to slow down your current work in progress, so I will try
to see IF/WHAT I can contribute, but will let you know before hand.​ :)



>
> The script is bash, not python.


​Yup, in fact, I wrote the script with the intention of adding the option
of attaching the diff to the JIRA issue to zk-merge-pr.py tool. It woud be
for the sake of documeting the patch in the JIRA. Maybe I will create a new
issue proposing this once we have the other things sorted out, and only if
you guys think this is worth doing.



> It doesn't make it patch available mainly because if we make it patch
> available, then it will trigger the Jira QA, which will find no patch. It
> is a bit messy to trigger this second build, so I'm reluctant in doing it.
> I can see two options:
>
> - Only do github pull requests, in which case "Patch Available" in our
> workflow means pull request available
> - Somehow detect that there is a pull request and no trigger the Jira QA
>

​IMHO, the the first option is less brittle and effective.

Edward

Re: QA github pre-commit queue

[Flavio Junqueira]

I have created ZOOKEEPER-2624 for this and have adapted the existing script to 
work with the git pull request. Currently, I have a separate script, but there 
is a lot of duplication, so it sounds very plausible to merge them.

The pull request for the jira has lots of meaningless commits because I was 
testing my changes. The current state is that I'm able to trigger and produce a 
report to the jira as we have with the jira QA. If we are to merge these 
changes in, then I'll close the pull request and resubmit the changes. Feel 
free to contribute to my changes and suggest a different way in the jira. We 
can definitely work together on this, I just want to have this working soon.

The script is bash, not python. It doesn't make it patch available mainly 
because if we make it patch available, then it will trigger the Jira QA, which 
will find no patch. It is a bit messy to trigger this second build, so I'm 
reluctant in doing it. I can see two options:

- Only do github pull requests, in which case "Patch Available" in our workflow 
means pull request available
- Somehow detect that there is a pull request and no trigger the Jira QA

-Flavio

> On 31 Oct 2016, at 17:18, Edward Ribeiro  wrote:
> 
> Hi Flavio,
> 
> Nice you have mentioned that 'cause I had written a small python script
> last Friday that gets the Github PR diff and post it on JIRA as an
> attachement. It's a git diff, not a svn one, but the jenkins processing
> queue is applying the patches to git now, right?
> 
> https://gist.github.com/eribeiro/be42ff9dcbc50ebd4b2779ef9f866cba
> 
> I guess we can incorporate parts of the script above in the QA queue or
> zk-merge-pr.py. It doesn't set up the issue as 'Patch Available', but it
> should be easy to do this. Also, it doesn't cancel the patch if the PR is
> closed, but I guess it can also be done (although I am afraid I don't know
> how to do this automatically).
> 
> The zk-merge-pr.py automatically resolve the jira issue once the PR is
> merged.
> 
> Edward
> 
> On Sat, Oct 29, 2016 at 1:23 PM, Flavio Junqueira  wrote:
> 
>> Another thing I forgot to mention and I noticed we are missing is to make
>> a jira patch available when a pull request is submitted and cancel the
>> patch if the pull request is closed without merging. I think there is a way
>> of doing it. It should also be possible to resolve the jira automatically
>> upon committing the pull request.
>> 
>> -Flavio
>> 
>>> On 28 Oct 2016, at 15:14, Flavio Junqueira  wrote:
>>> 
>>> Here is my progress so far. I managed to get the build to trigger with a
>> pull request and pull request changes:
>>> 
>>> https://builds.apache.org/view/PreCommit%20Builds/job/PreCom
>> mit-ZOOKEEPER-github-pr-build/
>>> 
>>> I had to hack into it a bit because our original pre-commit build is
>> really focused on getting patch files from jira, applying the patch, and
>> building it (check src/java/test/bin/test-patch.sh). I hardcoded the
>> build commands into the queue configuration, which works but makes it hard
>> for others without access to jenkins to contribute, so moving forward we
>> should script it.
>>> 
>>> There is clearly some polishing to be done, so please report back so
>> that we can try to fix it.
>>> 
>>> -Flavio
>>> 
 On 27 Oct 2016, at 22:24, Flavio Junqueira  wrote:
 
 Yeah, I tried to trigger the 761 manually and it didn't work. I need to
>> work on the manual trigger.
 
 The issue with your PR 94 is likely to be a bug in the config that I
>> think I fixed now. I need to create a test PR to debug it.
 
 One problem is that builds.apache.org  is
>> super slow, so it is difficult to work on the configuration right now. I'll
>> work some more on my morning because it shouldn't be as busy.
 
 -Flavio
 
> On 27 Oct 2016, at 22:19, Michael Han  wrote:
> 
> I saw the pre-commit build from the new bot (
> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/)
>> for
> ZOOKEEPER-761. There are two issues:
> 
> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
> Available".  Exiting."
> * The build result was sent to dev list, but the result was not posted
>> on
> JIRA, as previous build bot did.
> 
> Still no sign of pre-commit build triggered by my PR94, btw.
> 
> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed 
>> wrote:
> 
>> i also pushed a new version for
>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>> might
>> be tricky since there are attached patches and a pr. should the pr
>> still be
>> qaed?
>> 
>> 
>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han 
>> wrote:
>> 
>>> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>> activity.
>>> 
>>> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira 
>> wrote:
>>> 
 Ok, I have created this queue: PreCommit-ZOOKEEPER-githu

Re: QA github pre-commit queue

[Edward Ribeiro]

Hi Flavio,

Nice you have mentioned that 'cause I had written a small python script
last Friday that gets the Github PR diff and post it on JIRA as an
attachement. It's a git diff, not a svn one, but the jenkins processing
queue is applying the patches to git now, right?

https://gist.github.com/eribeiro/be42ff9dcbc50ebd4b2779ef9f866cba

I guess we can incorporate parts of the script above in the QA queue or
zk-merge-pr.py. It doesn't set up the issue as 'Patch Available', but it
should be easy to do this. Also, it doesn't cancel the patch if the PR is
closed, but I guess it can also be done (although I am afraid I don't know
how to do this automatically).

The zk-merge-pr.py automatically resolve the jira issue once the PR is
merged.

Edward

On Sat, Oct 29, 2016 at 1:23 PM, Flavio Junqueira  wrote:

> Another thing I forgot to mention and I noticed we are missing is to make
> a jira patch available when a pull request is submitted and cancel the
> patch if the pull request is closed without merging. I think there is a way
> of doing it. It should also be possible to resolve the jira automatically
> upon committing the pull request.
>
> -Flavio
>
> > On 28 Oct 2016, at 15:14, Flavio Junqueira  wrote:
> >
> > Here is my progress so far. I managed to get the build to trigger with a
> pull request and pull request changes:
> >
> > https://builds.apache.org/view/PreCommit%20Builds/job/PreCom
> mit-ZOOKEEPER-github-pr-build/
> >
> > I had to hack into it a bit because our original pre-commit build is
> really focused on getting patch files from jira, applying the patch, and
> building it (check src/java/test/bin/test-patch.sh). I hardcoded the
> build commands into the queue configuration, which works but makes it hard
> for others without access to jenkins to contribute, so moving forward we
> should script it.
> >
> > There is clearly some polishing to be done, so please report back so
> that we can try to fix it.
> >
> > -Flavio
> >
> >> On 27 Oct 2016, at 22:24, Flavio Junqueira  wrote:
> >>
> >> Yeah, I tried to trigger the 761 manually and it didn't work. I need to
> work on the manual trigger.
> >>
> >> The issue with your PR 94 is likely to be a bug in the config that I
> think I fixed now. I need to create a test PR to debug it.
> >>
> >> One problem is that builds.apache.org  is
> super slow, so it is difficult to work on the configuration right now. I'll
> work some more on my morning because it shouldn't be as busy.
> >>
> >> -Flavio
> >>
> >>> On 27 Oct 2016, at 22:19, Michael Han  wrote:
> >>>
> >>> I saw the pre-commit build from the new bot (
> >>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/)
> for
> >>> ZOOKEEPER-761. There are two issues:
> >>>
> >>> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
> >>> Available".  Exiting."
> >>> * The build result was sent to dev list, but the result was not posted
> on
> >>> JIRA, as previous build bot did.
> >>>
> >>> Still no sign of pre-commit build triggered by my PR94, btw.
> >>>
> >>> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed 
> wrote:
> >>>
>  i also pushed a new version for
>  https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>  might
>  be tricky since there are attached patches and a pr. should the pr
> still be
>  qaed?
> 
> 
>  On Thu, Oct 27, 2016 at 12:04 PM, Michael Han 
> wrote:
> 
> > Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>  activity.
> >
> > On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira 
>  wrote:
> >
> >> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build.
> I
> >> have configured it and would kindly appreciate if anyone could
> update a
> > PR
> >> to test it.
> >>
> >> -Flavio
> >>
> >>
> >>> On 27 Oct 2016, at 16:57, Edward Ribeiro  >
> >> wrote:
> >>>
> >>> Cool! Thanks for the heads up. :)
> >>>
> >>> Cheers
> >>>
> >>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" 
> >> escreveu:
> >>>
>  There is no need to create an INFRA jira, I'm taking care of it,
>  stay
>  tuned. In the meanwhile, please submit patches as usual through
> jira
> > to
>  trigger QA.
> 
>  -Flavio
> 
> > On 27 Oct 2016, at 16:54, Edward Ribeiro <
> edward.ribe...@gmail.com
> >
>  wrote:
> >
> > Dear community,
> >
> > As part of the github move, we are still lacking the plumbing
> that
> >> allows
> > to run Jenkins CI tests, etc, on open Pull Requests. Please,
> take a
> >> look
>  at
> > Kafka pending PR at Github to see what I am referring to.
> >
> > Any committer could open an INFRA JIRA to address this?
> >
> > Best regards,
> > Eddie
> 
> 
> >>
> >>
> >
> >
> > --
>

Re: QA github pre-commit queue

[Flavio Junqueira]

Another thing I forgot to mention and I noticed we are missing is to make a 
jira patch available when a pull request is submitted and cancel the patch if 
the pull request is closed without merging. I think there is a way of doing it. 
It should also be possible to resolve the jira automatically upon committing 
the pull request.

-Flavio

> On 28 Oct 2016, at 15:14, Flavio Junqueira  wrote:
> 
> Here is my progress so far. I managed to get the build to trigger with a pull 
> request and pull request changes:
> 
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-ZOOKEEPER-github-pr-build/
> 
> I had to hack into it a bit because our original pre-commit build is really 
> focused on getting patch files from jira, applying the patch, and building it 
> (check src/java/test/bin/test-patch.sh). I hardcoded the build commands into 
> the queue configuration, which works but makes it hard for others without 
> access to jenkins to contribute, so moving forward we should script it.
> 
> There is clearly some polishing to be done, so please report back so that we 
> can try to fix it.
> 
> -Flavio
> 
>> On 27 Oct 2016, at 22:24, Flavio Junqueira  wrote:
>> 
>> Yeah, I tried to trigger the 761 manually and it didn't work. I need to work 
>> on the manual trigger.
>> 
>> The issue with your PR 94 is likely to be a bug in the config that I think I 
>> fixed now. I need to create a test PR to debug it.
>> 
>> One problem is that builds.apache.org  is super 
>> slow, so it is difficult to work on the configuration right now. I'll work 
>> some more on my morning because it shouldn't be as busy.
>> 
>> -Flavio
>> 
>>> On 27 Oct 2016, at 22:19, Michael Han  wrote:
>>> 
>>> I saw the pre-commit build from the new bot (
>>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
>>> ZOOKEEPER-761. There are two issues:
>>> 
>>> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
>>> Available".  Exiting."
>>> * The build result was sent to dev list, but the result was not posted on
>>> JIRA, as previous build bot did.
>>> 
>>> Still no sign of pre-commit build triggered by my PR94, btw.
>>> 
>>> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed  wrote:
>>> 
 i also pushed a new version for
 https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
 might
 be tricky since there are attached patches and a pr. should the pr still be
 qaed?
 
 
 On Thu, Oct 27, 2016 at 12:04 PM, Michael Han  wrote:
 
> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
 activity.
> 
> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira 
 wrote:
> 
>> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
>> have configured it and would kindly appreciate if anyone could update a
> PR
>> to test it.
>> 
>> -Flavio
>> 
>> 
>>> On 27 Oct 2016, at 16:57, Edward Ribeiro 
>> wrote:
>>> 
>>> Cool! Thanks for the heads up. :)
>>> 
>>> Cheers
>>> 
>>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" 
>> escreveu:
>>> 
 There is no need to create an INFRA jira, I'm taking care of it,
 stay
 tuned. In the meanwhile, please submit patches as usual through jira
> to
 trigger QA.
 
 -Flavio
 
> On 27 Oct 2016, at 16:54, Edward Ribeiro  
 wrote:
> 
> Dear community,
> 
> As part of the github move, we are still lacking the plumbing that
>> allows
> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
>> look
 at
> Kafka pending PR at Github to see what I am referring to.
> 
> Any committer could open an INFRA JIRA to address this?
> 
> Best regards,
> Eddie
 
 
>> 
>> 
> 
> 
> --
> Cheers
> Michael.
> 
 
>>> 
>>> 
>>> 
>>> -- 
>>> Cheers
>>> Michael.
>> 
> 

Re: QA github pre-commit queue

[Flavio Junqueira]

Here is my progress so far. I managed to get the build to trigger with a pull 
request and pull request changes:

https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-ZOOKEEPER-github-pr-build/

I had to hack into it a bit because our original pre-commit build is really 
focused on getting patch files from jira, applying the patch, and building it 
(check src/java/test/bin/test-patch.sh). I hardcoded the build commands into 
the queue configuration, which works but makes it hard for others without 
access to jenkins to contribute, so moving forward we should script it.

There is clearly some polishing to be done, so please report back so that we 
can try to fix it.

-Flavio

> On 27 Oct 2016, at 22:24, Flavio Junqueira  wrote:
> 
> Yeah, I tried to trigger the 761 manually and it didn't work. I need to work 
> on the manual trigger.
> 
> The issue with your PR 94 is likely to be a bug in the config that I think I 
> fixed now. I need to create a test PR to debug it.
> 
> One problem is that builds.apache.org  is super 
> slow, so it is difficult to work on the configuration right now. I'll work 
> some more on my morning because it shouldn't be as busy.
> 
> -Flavio
> 
>> On 27 Oct 2016, at 22:19, Michael Han  wrote:
>> 
>> I saw the pre-commit build from the new bot (
>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
>> ZOOKEEPER-761. There are two issues:
>> 
>> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
>> Available".  Exiting."
>> * The build result was sent to dev list, but the result was not posted on
>> JIRA, as previous build bot did.
>> 
>> Still no sign of pre-commit build triggered by my PR94, btw.
>> 
>> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed  wrote:
>> 
>>> i also pushed a new version for
>>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>>> might
>>> be tricky since there are attached patches and a pr. should the pr still be
>>> qaed?
>>> 
>>> 
>>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han  wrote:
>>> 
 Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>>> activity.
 
 On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira 
>>> wrote:
 
> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
> have configured it and would kindly appreciate if anyone could update a
 PR
> to test it.
> 
> -Flavio
> 
> 
>> On 27 Oct 2016, at 16:57, Edward Ribeiro 
> wrote:
>> 
>> Cool! Thanks for the heads up. :)
>> 
>> Cheers
>> 
>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" 
> escreveu:
>> 
>>> There is no need to create an INFRA jira, I'm taking care of it,
>>> stay
>>> tuned. In the meanwhile, please submit patches as usual through jira
 to
>>> trigger QA.
>>> 
>>> -Flavio
>>> 
 On 27 Oct 2016, at 16:54, Edward Ribeiro >>> 
>>> wrote:
 
 Dear community,
 
 As part of the github move, we are still lacking the plumbing that
> allows
 to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
> look
>>> at
 Kafka pending PR at Github to see what I am referring to.
 
 Any committer could open an INFRA JIRA to address this?
 
 Best regards,
 Eddie
>>> 
>>> 
> 
> 
 
 
 --
 Cheers
 Michael.
 
>>> 
>> 
>> 
>> 
>> -- 
>> Cheers
>> Michael.
> 

Re: QA github pre-commit queue

[Flavio Junqueira]

Yeah, I tried to trigger the 761 manually and it didn't work. I need to work on 
the manual trigger.

The issue with your PR 94 is likely to be a bug in the config that I think I 
fixed now. I need to create a test PR to debug it.

One problem is that builds.apache.org  is super 
slow, so it is difficult to work on the configuration right now. I'll work some 
more on my morning because it shouldn't be as busy.

-Flavio

> On 27 Oct 2016, at 22:19, Michael Han  wrote:
> 
> I saw the pre-commit build from the new bot (
> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
> ZOOKEEPER-761. There are two issues:
> 
> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
> Available".  Exiting."
> * The build result was sent to dev list, but the result was not posted on
> JIRA, as previous build bot did.
> 
> Still no sign of pre-commit build triggered by my PR94, btw.
> 
> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed  wrote:
> 
>> i also pushed a new version for
>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>> might
>> be tricky since there are attached patches and a pr. should the pr still be
>> qaed?
>> 
>> 
>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han  wrote:
>> 
>>> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>> activity.
>>> 
>>> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira 
>> wrote:
>>> 
 Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
 have configured it and would kindly appreciate if anyone could update a
>>> PR
 to test it.
 
 -Flavio
 
 
> On 27 Oct 2016, at 16:57, Edward Ribeiro 
 wrote:
> 
> Cool! Thanks for the heads up. :)
> 
> Cheers
> 
> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" 
 escreveu:
> 
>> There is no need to create an INFRA jira, I'm taking care of it,
>> stay
>> tuned. In the meanwhile, please submit patches as usual through jira
>>> to
>> trigger QA.
>> 
>> -Flavio
>> 
>>> On 27 Oct 2016, at 16:54, Edward Ribeiro >> 
>> wrote:
>>> 
>>> Dear community,
>>> 
>>> As part of the github move, we are still lacking the plumbing that
 allows
>>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
 look
>> at
>>> Kafka pending PR at Github to see what I am referring to.
>>> 
>>> Any committer could open an INFRA JIRA to address this?
>>> 
>>> Best regards,
>>> Eddie
>> 
>> 
 
 
>>> 
>>> 
>>> --
>>> Cheers
>>> Michael.
>>> 
>> 
> 
> 
> 
> -- 
> Cheers
> Michael.

Re: QA github pre-commit queue

[Michael Han]

I saw the pre-commit build from the new bot (
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
ZOOKEEPER-761. There are two issues:

* The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
Available".  Exiting."
* The build result was sent to dev list, but the result was not posted on
JIRA, as previous build bot did.

Still no sign of pre-commit build triggered by my PR94, btw.

On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed  wrote:

> i also pushed a new version for
> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
> might
> be tricky since there are attached patches and a pr. should the pr still be
> qaed?
>
>
> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han  wrote:
>
> > Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
> activity.
> >
> > On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira 
> wrote:
> >
> > > Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
> > > have configured it and would kindly appreciate if anyone could update a
> > PR
> > > to test it.
> > >
> > > -Flavio
> > >
> > >
> > > > On 27 Oct 2016, at 16:57, Edward Ribeiro 
> > > wrote:
> > > >
> > > > Cool! Thanks for the heads up. :)
> > > >
> > > > Cheers
> > > >
> > > > Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" 
> > > escreveu:
> > > >
> > > >> There is no need to create an INFRA jira, I'm taking care of it,
> stay
> > > >> tuned. In the meanwhile, please submit patches as usual through jira
> > to
> > > >> trigger QA.
> > > >>
> > > >> -Flavio
> > > >>
> > > >>> On 27 Oct 2016, at 16:54, Edward Ribeiro  >
> > > >> wrote:
> > > >>>
> > > >>> Dear community,
> > > >>>
> > > >>> As part of the github move, we are still lacking the plumbing that
> > > allows
> > > >>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
> > > look
> > > >> at
> > > >>> Kafka pending PR at Github to see what I am referring to.
> > > >>>
> > > >>> Any committer could open an INFRA JIRA to address this?
> > > >>>
> > > >>> Best regards,
> > > >>> Eddie
> > > >>
> > > >>
> > >
> > >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>



-- 
Cheers
Michael.

Re: QA github pre-commit queue

[Benjamin Reed]

i also pushed a new version for
https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one might
be tricky since there are attached patches and a pr. should the pr still be
qaed?


On Thu, Oct 27, 2016 at 12:04 PM, Michael Han  wrote:

> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot activity.
>
> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira  wrote:
>
> > Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
> > have configured it and would kindly appreciate if anyone could update a
> PR
> > to test it.
> >
> > -Flavio
> >
> >
> > > On 27 Oct 2016, at 16:57, Edward Ribeiro 
> > wrote:
> > >
> > > Cool! Thanks for the heads up. :)
> > >
> > > Cheers
> > >
> > > Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" 
> > escreveu:
> > >
> > >> There is no need to create an INFRA jira, I'm taking care of it, stay
> > >> tuned. In the meanwhile, please submit patches as usual through jira
> to
> > >> trigger QA.
> > >>
> > >> -Flavio
> > >>
> > >>> On 27 Oct 2016, at 16:54, Edward Ribeiro 
> > >> wrote:
> > >>>
> > >>> Dear community,
> > >>>
> > >>> As part of the github move, we are still lacking the plumbing that
> > allows
> > >>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
> > look
> > >> at
> > >>> Kafka pending PR at Github to see what I am referring to.
> > >>>
> > >>> Any committer could open an INFRA JIRA to address this?
> > >>>
> > >>> Best regards,
> > >>> Eddie
> > >>
> > >>
> >
> >
>
>
> --
> Cheers
> Michael.
>

Re: QA github pre-commit queue

[Michael Han]

Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot activity.

On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira  wrote:

> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
> have configured it and would kindly appreciate if anyone could update a PR
> to test it.
>
> -Flavio
>
>
> > On 27 Oct 2016, at 16:57, Edward Ribeiro 
> wrote:
> >
> > Cool! Thanks for the heads up. :)
> >
> > Cheers
> >
> > Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" 
> escreveu:
> >
> >> There is no need to create an INFRA jira, I'm taking care of it, stay
> >> tuned. In the meanwhile, please submit patches as usual through jira to
> >> trigger QA.
> >>
> >> -Flavio
> >>
> >>> On 27 Oct 2016, at 16:54, Edward Ribeiro 
> >> wrote:
> >>>
> >>> Dear community,
> >>>
> >>> As part of the github move, we are still lacking the plumbing that
> allows
> >>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
> look
> >> at
> >>> Kafka pending PR at Github to see what I am referring to.
> >>>
> >>> Any committer could open an INFRA JIRA to address this?
> >>>
> >>> Best regards,
> >>> Eddie
> >>
> >>
>
>


-- 
Cheers
Michael.

Re: QA github pre-commit queue

[Flavio Junqueira]

Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I have 
configured it and would kindly appreciate if anyone could update a PR to test 
it.

-Flavio


> On 27 Oct 2016, at 16:57, Edward Ribeiro  wrote:
> 
> Cool! Thanks for the heads up. :)
> 
> Cheers
> 
> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira"  escreveu:
> 
>> There is no need to create an INFRA jira, I'm taking care of it, stay
>> tuned. In the meanwhile, please submit patches as usual through jira to
>> trigger QA.
>> 
>> -Flavio
>> 
>>> On 27 Oct 2016, at 16:54, Edward Ribeiro 
>> wrote:
>>> 
>>> Dear community,
>>> 
>>> As part of the github move, we are still lacking the plumbing that allows
>>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look
>> at
>>> Kafka pending PR at Github to see what I am referring to.
>>> 
>>> Any committer could open an INFRA JIRA to address this?
>>> 
>>> Best regards,
>>> Eddie
>> 
>> 

Re: QA github pre-commit queue

[Edward Ribeiro]

Cool! Thanks for the heads up. :)

Cheers

Em 27 de out de 2016 1:56 PM, "Flavio Junqueira"  escreveu:

> There is no need to create an INFRA jira, I'm taking care of it, stay
> tuned. In the meanwhile, please submit patches as usual through jira to
> trigger QA.
>
> -Flavio
>
> > On 27 Oct 2016, at 16:54, Edward Ribeiro 
> wrote:
> >
> > Dear community,
> >
> > As part of the github move, we are still lacking the plumbing that allows
> > to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look
> at
> > Kafka pending PR at Github to see what I am referring to.
> >
> > Any committer could open an INFRA JIRA to address this?
> >
> > Best regards,
> > Eddie
>
>

Re: QA github pre-commit queue

[Flavio Junqueira]

There is no need to create an INFRA jira, I'm taking care of it, stay tuned. In 
the meanwhile, please submit patches as usual through jira to trigger QA.

-Flavio

> On 27 Oct 2016, at 16:54, Edward Ribeiro  wrote:
> 
> Dear community,
> 
> As part of the github move, we are still lacking the plumbing that allows
> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look at
> Kafka pending PR at Github to see what I am referring to.
> 
> Any committer could open an INFRA JIRA to address this?
> 
> Best regards,
> Eddie

QA github pre-commit queue

[Edward Ribeiro]

Dear community,

As part of the github move, we are still lacking the plumbing that allows
to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look at
Kafka pending PR at Github to see what I am referring to.

Any committer could open an INFRA JIRA to address this?

Best regards,
Eddie