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