drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Burgess <mattyb...@gmail.com>
Subject Re: [DISCUSS] Allowing the option to use github pull requests in place of reviewboard
Date Wed, 08 Jul 2015 02:41:38 GMT
If this desired solution is not available, feasible, or otherwise painful, I
can follow up with our folks, possibly contributing some Python scripts to
handle these tasks, as we are also trying to tie GitHub to Jira without IT
being in the critical path (but of course informed). Personally, I've been
looking at a Continuous Delivery pipeline from GitHub to Jira/ReviewNinja
<http://www.review.ninja/>  to Travis <https://travis-ci.org/> , then Travis
to Bintray <https://bintray.com/> , etc.

From:  Jason Altekruse <altekrusejason@gmail.com>
Reply-To:  <dev@drill.apache.org>
Date:  Tuesday, July 7, 2015 at 8:51 PM
To:  <dev@drill.apache.org>
Subject:  Re: [DISCUSS] Allowing the option to use github pull requests in
place of reviewboard

We don't actually have permission to change the JIRA instance ourselves,
but we can open an apache infra ticket for it. Here is a blog post about
some integration they added fairly recently. It says here that they need to
enable several features as requested by particular projects. Is there
anything listed here we don't want turned on?

 I'm going to do a little more digging, because it is not clear to me if
the actual content of the patches makes it back to the JIRA with this
automatic integration. It would be nice to remove the extra step of
generating and uploading patch files, but we want to make sure we have the
code changes stored on apache infra somehow.

https://blogs.apache.org/infra/entry/improved_integration_between_apache_and

On Tue, Jul 7, 2015 at 5:41 PM, Jim Scott <jscott@maprtech.com> wrote:

>  The main requirement is that it requires a person with a high enough
>  permission level in JIRA to setup the connector to github. They also need
>  to be able to configure the github side as well.
> 
>  On Tue, Jul 7, 2015 at 7:38 PM, Matt Burgess <mattyb149@gmail.com> wrote:
> 
>>  > Is it difficult to get the DVCS connector installed/enabled for Drill's
>>  > Jira? I know for my company it's been sitting on the to-do list for a
>>  > while, but we haven't actually installed it.
>>  >
>>  > Sent from my iPhone
>>  >
>>>  > > On Jul 7, 2015, at 8:25 PM, Jim Scott <jscott@maprtech.com>
wrote:
>>>  > >
>>>  > > The instructions for setting up JIRA to integrate with github is here:
>>>  > > http://blogs.atlassian.com/2014/04/connecting-jira-6-2-github/
>>>  > >
>>>  > > As Ted points out, in this case any comment on a commit that says
>>  > DRILL-NNN
>>>  > > would get found by JIRA and would automatically be added to the Jira
>>  > ticket
>>>  > > for the history to be reviewed.
>>>  > >
>>>>  > >> On Tue, Jul 7, 2015 at 4:32 PM, Ted Dunning <ted.dunning@gmail.com>
>>  > wrote:
>>>>  > >>
>>>>  > >> The only Apache requirement is that the mailing list + JIRA
makes
>  sense
>>  > and
>>>>  > >> is readable as a history of the project.  Keeping the issues
on >>>>
github
>>>>  > >> won't fly.
>>>>  > >>
>>>>  > >> It is pretty easy to get github to hook into JIRA pretty well
if the
>  PR
>>>>  > >> messages have a reference to the JIRA.  I don't know the details.
>>>>  > >>
>>>>  > >> The suggestion to require the person who merges to include
a
>>>> code-word
>>  > in
>>>>  > >> the message is a very good one.
>>>>  > >>
>>>>  > >>
>>>>  > >>
>>>>>  > >>> On Tue, Jul 7, 2015 at 1:35 PM, Jacques Nadeau <jacques@apache.org>
>>  > wrote:
>>>>>  > >>>
>>>>>  > >>> I don't think we need anything formal.  Do you want
to propose a
few
>>>>  > >> simple
>>>>>  > >>> guidelines?
>>>>>  > >>>
>>>>>  > >>> E.g. Should we link to PRs on JIRA, do we really need
a JIRA, the
>>  > merger
>>>>  > >> is
>>>>>  > >>> responsible for including the "close #123" syntax
in the commit,
etc.
>>>>>  > >>>
>>>>>  > >>> On Tue, Jul 7, 2015 at 1:33 PM, Jason Altekruse <
>>>>  > >> altekrusejason@gmail.com>
>>>>>  > >>> wrote:
>>>>>  > >>>
>>>>>>  > >>>> Seems to be enough consensus that this is
beneficial. I took a
look
>  at
>>>>>  > >>> the
>>>>>>  > >>>> bylaws and it doesn't say anything specific
there about an >>>>>>
official
>>>>>  > >>> review
>>>>>>  > >>>> process. Is there a need to start a separate
vote thread before
>  making
>>>>  > >> a
>>>>>>  > >>>> change like this?
>>>>>>  > >>>>
>>>>>>  > >>>> I would be in favor of allowing both for a
little bit, if it is a
>>>>>>  > >>>> significant improvement we can move to completely
deprecate
>>>>  > >> reviewboard.
>>>>>>  > >>>>
>>>>>>>  > >>>>> On Tue, Jul 7, 2015 at 1:14 PM, Jacques
Nadeau
>>>>>>> <jacques@apache.org
>>  >
>>>>>>  > >>>> wrote:
>>>>>>  > >>>>
>>>>>>>  > >>>>> What did we decide here?
>>>>>>>  > >>>>>
>>>>>>>  > >>>>> Are we going to move forward with
trying out pull requests?  If
so,
>>>>  > >> do
>>>>>  > >>> we
>>>>>>>  > >>>>> want to start having everyone do it
or suggest only one or two
do
>  it
>>>>  > >> to
>>>>>>>  > >>>>> start?
>>>>>>>  > >>>>>
>>>>>>>  > >>>>> thoughts?
>>>>>>>  > >>>>> Jacques
>>>>>>>  > >>>>>
>>>>>>>  > >>>>> On Wed, Jun 24, 2015 at 8:46 AM, Jacques
Nadeau <
>  jacques@apache.org>
>>>>>>>  > >>>>> wrote:
>>>>>>>  > >>>>>
>>>>>>>>  > >>>>>> I can't remember the rule.
 I think it was 3gb and 15
>>>>>>>> minutes.  In
>>>>>>  > >>>> order
>>>>>>>>  > >>>>>> to get under 3 gb, I think
we need to run single threaded.
Last I
>>>>>>>  > >>>>> checked,
>>>>>>>>  > >>>>>> running with 4 threads on
dedicated hardware completes in ~12
>>>>>  > >>> minutes.
>>>>>>>>  > >>>>>> However, the Travis instances
used to be really slow virtual
>>>>>  > >>> machines.
>>>>>>>  > >>>>> I'm
>>>>>>>>  > >>>>>> sure a solution can be found
but I think we'd need some
concerted
>>>>>>  > >>>> effort
>>>>>>>  > >>>>> on
>>>>>>>>  > >>>>>> reducing the test footprint.
>>>>>>>>  > >>>>>>
>>>>>>>>  > >>>>>> We talked before (Daniel's
suggestion) about treating more of
the
>>>>>  > >>> tests
>>>>>>>  > >>>>> as
>>>>>>>>  > >>>>>> integration tests.  This would
help as much of the test time
is
>>>>  > >> spent
>>>>>>>>  > >>>>>> starting and stopping Drillbits
for each test class.  If we
only
>>>>  > >> did
>>>>>>  > >>>> this
>>>>>>>>  > >>>>>> once for all those tests,
the footprint would be much
smaller.
>>>>>>>>  > >>>>>>
>>>>>>>>  > >>>>>>
>>>>>>>>  > >>>>>>
>>>>>>>>  > >>>>>> On Wed, Jun 24, 2015 at 8:37
AM, Ted Dunning <
>>>>  > >> ted.dunning@gmail.com>
>>>>>>>>  > >>>>>> wrote:
>>>>>>>>  > >>>>>>
>>>>>>>>>  > >>>>>>> On Wed, Jun 24, 2015
at 11:35 AM, Jacques Nadeau <
>>>>>  > >>> jacques@apache.org>
>>>>>>>>>  > >>>>>>> wrote:
>>>>>>>>>  > >>>>>>>
>>>>>>>>>>  > >>>>>>>> We tried Travis
before.  The problem is that travis's
nodes
>>>>  > >> aren't
>>>>>>>>>>  > >>>>>>>> substantial
enough to complete our test suite within
their
>>>>>  > >>> timeout.
>>>>>>>>>  > >>>>>>>
>>>>>>>>>  > >>>>>>> Haven't the tests
been substantially improved since then?
>>>>>>>>>  > >>>>>>>
>>>>>>>>>  > >>>>>>> Can the tests be segregated
into pieces so Travis can still
do
>>>>  > >> some
>>>>>>>  > >>>>> useful
>>>>>>>>>  > >>>>>>> work?
>>  >
> 




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