drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-3987) Create a POC VV extraction
Date Wed, 11 Nov 2015 00:57:11 GMT

    [ https://issues.apache.org/jira/browse/DRILL-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999711#comment-14999711

ASF GitHub Bot commented on DRILL-3987:

Github user jacques-n commented on the pull request:

    It seems like there are two points that Chris is asking about:
    1) The scale of this patch (is it too big?)
    2) The order of application between this patch and other patches (such as the allocator
    On (1): other than moving files, there are virtually no functional changes in this patch
and its purpose is extremely narrow in scope. (There are probably six or so separations between
interface and implementation.) Yes, there are a lot of files that were moved. The patch creates
five new modules and has to move the appropriate files into those directories. All changes
were focused on the same purpose of modularization. I also chose to limit any refactoring
required in these patches exactly to avoid this challenge. (Note the orange lines that I deferred
in the attached PPT). As such, I think it is unfair to characterize a modularization patch
by counting the number of files that were involved. 
    On (2): We typically order things in the order that they are ready to be merged. If this
is a reasonable patch and is ready to be merged, it should be merged. If another patch has
been reviewed, passes functional (and performance regression as appropriate) and is ready
to be merged, it should be. In general, patches that are ready are ahead of patches that aren't
    Specifically on the allocator patch, on numerous occasions we have held up commits to
master (and releases) to try get the allocator patch merged. On each occasion, we've found
that it isn't ready to be merged due to concurrency design challenges. Let's address those
before worrying about staging of the patch. Once we get the algorithm right and everyone has
signed off on that, we can figure out rebasing on master and staging in relationship to other

> Create a POC VV extraction
> --------------------------
>                 Key: DRILL-3987
>                 URL: https://issues.apache.org/jira/browse/DRILL-3987
>             Project: Apache Drill
>          Issue Type: Sub-task
>            Reporter: Jacques Nadeau
>            Assignee: Jacques Nadeau
>             Fix For: 1.4.0
> I'd like to start by looking at an extraction that pulls out the base concepts of:
> buffer allocation, value vectors and complexwriter/fieldreader.
> I need to figure out how to resolve some of the cross-dependency issues (such as the
jdbc accessor connections).

This message was sent by Atlassian JIRA

View raw message