zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: [DISCUSS] QA github pre-commit queue
Date Fri, 18 Nov 2016 19:43:33 GMT
On Wed, Nov 9, 2016 at 6:46 PM, Flavio Junqueira <fpj@apache.org> wrote:

>
> > On 09 Nov 2016, at 10:39, Patrick Hunt <phunt@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 <fpj@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 <hanm@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 <fpj@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.
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message