On Wed, Nov 9, 2016 at 6:46 PM, Flavio Junqueira <f...@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 <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. > >>> > >> > >
