You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Flavio Junqueira <fp...@apache.org> on 2016/11/02 15:58:17 UTC
Re: QA github pre-commit queue
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 <ed...@gmail.com> wrote:
>
> My comments below:
>
> On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira <fp...@apache.org> 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: [DISCUSS] QA github pre-commit queue
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
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 <ha...@cloudera.com> wrote:
> Git PR bot builds
> <https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/> 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 <ha...@cloudera.com> 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.ribeiro@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 <
> >> rgs@itevenworks.net>
> >> wrote:
> >>
> >> > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
> >> >
> >>
> >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>
>
>
> --
> Cheers
> Michael.
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Michael Han <ha...@cloudera.com>.
Git PR bot builds
<https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/> 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 <ha...@cloudera.com> 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 <ed...@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 <
>> rgs@itevenworks.net>
>> wrote:
>>
>> > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
>> >
>>
>
>
>
> --
> Cheers
> Michael.
>
--
Cheers
Michael.
Re: [DISCUSS] QA github pre-commit queue
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Nov 9, 2016 at 6:46 PM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > On 09 Nov 2016, at 10:39, Patrick Hunt <ph...@apache.org> 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 <fp...@apache.org>
> 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 <ha...@cloudera.com> 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.ribeiro@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 <
> >>>> rgs@itevenworks.net>
> >>>> wrote:
> >>>>
> >>>>> On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Cheers
> >>> Michael.
> >>>
> >>
>
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
> On 09 Nov 2016, at 10:39, Patrick Hunt <ph...@apache.org> 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 <fp...@apache.org> 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 <ha...@cloudera.com> 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.ribeiro@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 <
>>>> rgs@itevenworks.net>
>>>> wrote:
>>>>
>>>>> On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers
>>> Michael.
>>>
>>
Re: [DISCUSS] QA github pre-commit queue
Posted by Patrick Hunt <ph...@apache.org>.
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 <fp...@apache.org> 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 <ha...@cloudera.com> 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.ribeiro@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 <
> > > rgs@itevenworks.net>
> > > wrote:
> > >
> > > > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
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 <ha...@cloudera.com> 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 <ed...@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 <
> > rgs@itevenworks.net>
> > wrote:
> >
> > > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
> > >
> >
>
>
>
> --
> Cheers
> Michael.
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Michael Han <ha...@cloudera.com>.
+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 <ed...@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 <
> rgs@itevenworks.net>
> wrote:
>
> > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
> >
>
--
Cheers
Michael.
Re: [DISCUSS] QA github pre-commit queue
Posted by Edward Ribeiro <ed...@gmail.com>.
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 <rg...@itevenworks.net>
wrote:
> On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Raúl Gutiérrez Segalés <rg...@itevenworks.net>.
On 6 November 2016 at 11:54, Flavio Junqueira <fp...@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
[DISCUSS] QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
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 <fp...@apache.org> 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 <ed...@gmail.com> wrote:
>>
>> My comments below:
>>
>> On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira <fp...@apache.org> 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
>