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