>> From:Micah Kornfield
>> Send Time:2019年9月26日(星期四) 14:23
>> To:Neal Richardson
>> Cc:"Krisztián Szűcs" ; Wes McKinney <
>> wesmck...@gmail.com>; dev
>> Subject:Re: Timeline for 0.15.0
) 14:23
To:Neal Richardson
Cc:"Krisztián Szűcs" ; Wes McKinney
; dev
Subject:Re: Timeline for 0.15.0 release
Just an I've started the RC generation process off, the last commit from
master is [1]
I am currently waiting the crossbow builds (build-690 on
ursa-labs/crossbow)
gt; > > > > > > >> > >>
> >>>> > > > > > > > >> > >> > Thanks,
> >>>> > > > > > > > >> > >> > Micah
> >>>> >
gt;> > > > > > > > >> > >> > [1]
>>>> > > > > > > > >> > >>
>>>> > > > >
>>>> > > > https://cwiki.apache.org/confluence/display/ARROW/Rel
; > signing key to
>> > > > > > > > >> > >> >> the KEYS file in SVN (that's not very hard to
>> do). I
>> > > > > think it's fine
>> > > >
t; > > > >> > >> emkornfi...@gmail.com> wrote:
> > > > > > > >> > >> >> >
> > > > > > > >> > >> >> > SGTM, as well.
> > > > > > > >> > >> >> >
> > > > >
> > > >> > >> >> binary artifacts for the vote
> > > > > > > > >> > >> >>
> > > > > > > > >> > >> >> On Tue, Sep 17, 2019 at 10:55 PM Micah Kornfield <
> > > > > > > > >>
; a couple of concerns:
> > > > > > >> > >> >> > 1. In the past I've had trouble downloading and
> > > validating
> > > > > > >> > >> releases. I'm a
> > > > > > >>
. I'm a
> > > > > >> > >> >> > bit worried, that I might have similar problems doing
> > the necessary
> > > > > >> > >> uploads.
> > > > > >> > >> >> > 2. My internet connection will likely be not great
; > 2. My internet connection will likely be not great, I
> don't know if
> > > > >> > >> this
> > > > >> > >> >> > would make it even less likely to be successful.
> > > > >> > >> >> >
> > > > >&
would make it even less likely to be successful.
> > > >> > >> >> >
> > > >> > >> >> > Does it become problematic if somehow I would have to
> > > >> > >> >> > abandon the
> > > >> > >> process
> > > &
> >> > >> process
> > >> > >> >> > mid-release? Is there anyone who could serve as a backup?
> > >> > >> >> > Are the
> > >> > >> steps
> > >> > >> >&g
17, 2019 at 4:25 PM Neal Richardson <
> >> > >> neal.p.richard...@gmail.com>
> >> > >> >> > wrote:
> >> > >> >> >
> >> > >> >> > > Sounds good to me.
> >> > >> >> > >
&
;> > > Sounds good to me.
>> > >> >> > >
>> > >> >> > > Do we have a release manager yet? Any volunteers?
>> > >> >> > >
>> > >> >> > > Neal
>> > >> >> > >
&
; wesmck...@gmail.com>
> > >> wrote:
> > >> >> > >
> > >> >> > > > hi all,
> > >> >> > > >
> > >> >> > > > It looks like we're drawing close to be
> > > hi all,
> > >> >> > > >
> > >> >> > > > It looks like we're drawing close to be able to make the
> 0.15.0
> > >> >> > > > release. I would suggest "pencils down" at the end of this
> week
> > >> an
> release. I would suggest "pencils down" at the end of this week
> >> and
> >> >> > > > see if a release candidate can be produced next Monday September
> >> 23.
> >> >> > > > Any thoughts or objections?
> >&g
and
>> >> > > > see if a release candidate can be produced next Monday September
>> 23.
>> >> > > > Any thoughts or objections?
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Wes
>> >> > > >
>>
; > > >
> >> > > > > hi Eric -- yes, that's correct. I'm planning to amend the
> Format docs
> >> > > > > today regarding the EOS issue and also update the C++ library
> >> > > > >
> >> > > > > On Wed, Sep 1
s, that's correct. I'm planning to amend the Format docs
>> > > > > today regarding the EOS issue and also update the C++ library
>> > > > >
>> > > > > On Wed, Sep 11, 2019 at 11:21 AM Eric Erhardt
>> > > > > wrote:
>>
gt; wrote:
> > > > > >
> > > > > > I assume the plan is to merge the ARROW-6313-flatbuffer-alignment
> > > > branch into master before the 0.15 release, correct?
> > > > > >
> > > > > > BT
e the C# alignment changes are ready to be merged into
> > > the alignment branch - https://github.com/apache/arrow/pull/5280/
> > > > >
> > > > > Eric
> > > > >
> > > > > -Original Message-
> > >
> the alignment branch - https://github.com/apache/arrow/pull/5280/
> > > >
> > > > Eric
> > > >
> > > > -Original Message-
> > > > From: Micah Kornfield
> > > > Sent: Tuesday, September 10, 2019 10:24 PM
> > > > To:
ct?
> > >
> > > BTW - I believe the C# alignment changes are ready to be merged into
> the alignment branch - https://github.com/apache/arrow/pull/5280/
> > >
> > > Eric
> > >
> > > -Original Message-----
> > > From: Micah Kor
--Original Message-
> > From: Micah Kornfield
> > Sent: Tuesday, September 10, 2019 10:24 PM
> > To: Wes McKinney
> > Cc: dev ; niki.lj
> > Subject: Re: Timeline for 0.15.0 release
> >
> > I should have a little more bandwidth to help with so
:24 PM
> To: Wes McKinney
> Cc: dev ; niki.lj
> Subject: Re: Timeline for 0.15.0 release
>
> I should have a little more bandwidth to help with some of the packaging
> starting tomorrow and going into the weekend.
>
> On Tuesday, September 10, 2019, Wes McKinney wrote:
: Micah Kornfield
Sent: Tuesday, September 10, 2019 10:24 PM
To: Wes McKinney
Cc: dev ; niki.lj
Subject: Re: Timeline for 0.15.0 release
I should have a little more bandwidth to help with some of the packaging
starting tomorrow and going into the weekend.
On Tuesday, September 10, 2019, Wes
> > Java side code already checked in, other implementations seems not.
>>> > >
>>> > > iii. ARROW-6202: OutOfMemory in JdbcAdapter[4]
>>> > > Caused by trying to load all records in one contiguous batch, fixed
>>> by providing iterator API for iteratively reading in ARROW-6219[5].
g to load all records in one contiguous batch, fixed
>> by providing iterator API for iteratively reading in ARROW-6219[5].
>> > >
>> > > Thanks,
>> > > Ji Liu
>> > >
>> > > [1] https://github.com/apache/arrow/pull/4960
>> &g
row.apache.org/docs/ipc.html
> > > [3] https://issues.apache.org/jira/browse/ARROW-1875
> > > [4] https://issues.apache.org/jira/browse/ARROW-6202[5]
> https://issues.apache.org/jira/browse/ARROW-6219
> > >
> > >
> > >
> > >
ow.apache.org/docs/ipc.html
> > [3] https://issues.apache.org/jira/browse/ARROW-1875
> > [4] https://issues.apache.org/jira/browse/ARROW-6202[5]
> > https://issues.apache.org/jira/browse/ARROW-6219
> >
> >
> >
> > --
> > From:Wes McKinney
> > Send Time:2019年8月19日(
ROW-1875
> [4] https://issues.apache.org/jira/browse/ARROW-6202[5]
> https://issues.apache.org/jira/browse/ARROW-6219
>
>
>
> --
> From:Wes McKinney
> Send Time:2019年8月19日(星期一) 23:03
> To:dev
>
Time:2019年8月19日(星期一) 23:03
To:dev
Subject:Re: Timeline for 0.15.0 release
I'm going to work some on organizing the 0.15.0 backlog some this
week, if anyone wants to help with grooming (particularly for
languages other than C++/Python where I'm focusing) that would be
helpful. There have been almost
I'm going to work some on organizing the 0.15.0 backlog some this
week, if anyone wants to help with grooming (particularly for
languages other than C++/Python where I'm focusing) that would be
helpful. There have been almost 500 JIRA issues opened since the
0.14.0 release, so we should make sure
The Windows wheel issue in 0.14.1 seems to be
https://issues.apache.org/jira/browse/ARROW-6015
I think the root cause could be the Windows changes in
https://github.com/apache/arrow/commit/223ae744cc2a12c60cecb5db593263a03c13f85a
I would be appreciative if a volunteer would look into what was
On Thu, 15 Aug 2019 11:17:07 -0700
Micah Kornfield wrote:
> >
> > In C++ they are
> > independent, we could have 32-bit array lengths and variable-length
> > types with 64-bit offsets if we wanted (we just wouldn't be able to
> > have a List child with more than INT32_MAX elements).
>
> I
>
> In C++ they are
> independent, we could have 32-bit array lengths and variable-length
> types with 64-bit offsets if we wanted (we just wouldn't be able to
> have a List child with more than INT32_MAX elements).
I think the point is we could do this in C++ but we don't. I'm not sure we
would
On Thu, Aug 15, 2019 at 12:00 AM Micah Kornfield wrote:
>
> Hi Wes,
> >
> > Do these need to be dependent on the 64-bit array length discussion?
>
> We could hack something that can read the lower 32-bit range, so I guess
> not, but this leaves a bad taste in my mouth. I think there is likely
>
Hi Wes,
>
> Do these need to be dependent on the 64-bit array length discussion?
We could hack something that can read the lower 32-bit range, so I guess
not, but this leaves a bad taste in my mouth. I think there is likely
still enough time to have the discussion and get these implemented, one
Agreed with Wes.
Regards
Antoine.
Le 14/08/2019 à 20:30, Wes McKinney a écrit :
> For the record, I don't think we should hold a major release hostage
> if we aren't able to complete various feature milestones in time.
> Since it's been about 5-6 weeks since 0.14.0 we're coming close to the
For the record, I don't think we should hold a major release hostage
if we aren't able to complete various feature milestones in time.
Since it's been about 5-6 weeks since 0.14.0 we're coming close to the
desired 8-10 week timeline for major releases, so if we need to have
0.16.0 prior to 1.0.0,
On Wed, Aug 14, 2019 at 11:43 AM Micah Kornfield wrote:
>
> >
> > is there anything else that has come up that
> > definitely needs to happen before we can release again?
>
> We need to decide on a way forward for LargeList, LargeBinary, etc, types...
>
Do these need to be dependent on the
>
> is there anything else that has come up that
> definitely needs to happen before we can release again?
We need to decide on a way forward for LargeList, LargeBinary, etc, types...
On Tue, Aug 13, 2019 at 8:27 PM Wes McKinney wrote:
> hi folks,
>
> Since there have been a number of fairly
Is there a JIRA for the issue that caused us to pull the 0.14.1
Windows Python wheel installers? If we want to have working wheels for
0.15.0 we'll need a volunteer to help address whatever was wrong with
0.14.1.
On Tue, Aug 13, 2019 at 10:26 PM Wes McKinney wrote:
>
> hi folks,
>
> Since there
hi folks,
Since there have been a number of fairly serious issues (e.g.
ARROW-6060) since 0.14.1 that have been fixed I think we should start
planning of the next major release. Note that we still have some
format-related work (the Flatbuffers alignment issue) that ought to be
resolved (not a
45 matches
Mail list logo
