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 <h...@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.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 <f...@apache.org> wrote: >> > >> > > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for >> > reviewing. >> > > >> > > The QA for pull requests should be working for pull requests agains >> > > master, but let's keep an eye and polish any rough edges that might >> still >> > > be there. >> > > >> > > With ZOOKEEPER-2624 in, there is one last major decision we need to >> make >> > > to wrap this up. The pull request QA currently do not make a jira >> patch >> > > available. This is intentional because making it patch available will >> > > trigger the original Jira QA, which will be confusing because we will >> > see a >> > > failure (I haven't tested, but I think that's what's going to >> happen). If >> > > we change the script to make the Jira patch available, then we need to >> > > either: >> > > >> > > 1- Disable the Jira QA altogether, which means that we will only have >> > pull >> > > request QA available >> > > 2- Make the Jira QA script spot that there is a pull request available >> > and >> > > not build it. >> > > >> > > I'm wondering if folks would be ok with only having patches submitted >> via >> > > pull requests or if we should continue to support the old Jira QA. >> > > >> > >> > I am +1 on only having patches submitted via PRs, it's simpler to only >> have >> > to support one method. Thanks Flavio for making this happen! >> > >> > >> > -rgs >> > >> > > > > -- > Cheers > Michael. > -- Cheers Michael.
