RE: [VOTE] Apache POI 3.15 (RC2)

2016-09-15 Thread Allison, Timothy B.
With the exception of the ppt master slide text, the content looks consistent 
across the POI file types.

Found two bugs in my eval code, but no regressions that would hold up the 
release :)



RE: [VOTE] Apache POI 3.15 (RC2)

2016-09-15 Thread Allison, Timothy B.
All thanks to Luis Filipe Nassif for diagnosis and the patch!

> I have some minor modifications/simplifications
Y, I wanted to change as little as possible.  It is probably better to move all 
of the checks we do for "is this a cleaner" in unmap() up to the point where we 
add to the buffer.  It felt suboptimal (but completely reasonable for now) to 
rely on ByteBuffer.allocate() to create something that didn't need to be 
cleaned...across all versions of Java, etc.

-Original Message-
From: Dominik Stadler [mailto:dominik.stad...@gmx.at] 
Sent: Thursday, September 15, 2016 9:15 AM
To: POI Developers List <dev@poi.apache.org>
Subject: Re: [VOTE] Apache POI 3.15 (RC2)

Hi,

The mem-leak patch looks good and sane!

I am still not sure how they end up with such a large amount of allocated 
memory for one file, but it is surely better to not keep the buffers if we do 
not need the special handling during close() anyway.

I have some minor modifications/simplifications around these statements that I 
will apply post-release

Dominik.

On Thu, Sep 15, 2016 at 2:01 PM, Allison, Timothy B. <talli...@mitre.org>
wrote:

> >* I'll take a look at the patch on TIKA-2058, if it's low-risk it can 
> >go
> in
> I committed Luis Filipe Nassif's patch last night (BUG 60140).  Please 
> do take a look to make sure the change doesn't cause any unforeseen problems.
>
> >> * I could do with input from those who use HSLF about whether to 
> >> hold
> up another RC for the issue below.
> > I've already patched the HSLF issue yesterday
>
> Thank you, Andi!
>
>
> -Original Message-
> From: David North [mailto:dtn-...@corefiling.co.uk]
> Sent: Thursday, September 15, 2016 4:16 AM
> To: dev@poi.apache.org
> Subject: Re: [VOTE] Apache POI 3.15 (RC2)
>
> OK, current status:
>
> * I'll take a look at the patch on TIKA-2058, if it's low-risk it can 
> go in
> * I could do with input from those who use HSLF about whether to hold 
> up another RC for the issue below.
>
> I may not have time to roll RC3 tonight; if not I'll do it tomorrow 
> night which gives us all the weekend to try it out.
>
> Thanks,
> David
>
> On 14/09/16 21:39, Javen O'Neal wrote:
> > The HSLF footer text regression is still open.
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=60003
> > https://issues.apache.org/jira/browse/TIKA-2013
> >
> > On Sep 14, 2016 12:43 PM, "Dominik Stadler" <dominik.stad...@gmx.at>
> wrote:
> >
> >> Hi,
> >>
> >> I'd also rather keep it as is to not break it multiple times.
> >>
> >> Dominik.
> >>
> >> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal 
> >> <javenon...@gmail.com>
> >> wrote:
> >>
> >>> CellValue#getCellType was changed to return an enum after the 3.14
> >> release.
> >>> I reverted that signature change in r1760607 (see bug 59791 
> >>> comment
> 13).
> >>>
> >>> For bug 59907, I broke backwards compatibility for ClientAnchor 
> >>> (both
> >> HSSF
> >>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and 
> >>> included in POI 3.14 final) without the usual 2 release 
> >>> deprecation warning. The question is do I restore the behavior of 
> >>> 3.13 (breaking code a second
> >> time
> >>> for anyone who upgraded their code to 3.14, and a third time 
> >>> whenever we retire the int code), or do we leave it as is and ask 
> >>> users to upgrade to the enum getter now?
> >>>
> >>> Looking at the code example from bug 59907 comment 1, the fix for 
> >>> them is
> >>> simple: delete ".getValue()".
> >>>
> >>> On Sep 13, 2016 09:06, "Javen O'Neal" <javenon...@gmail.com> wrote:
> >>>
> >>>> I will commit a fix for this today with the goal for backwards 
> >>>> compatibility.
> >>>>
> >>>> Here's the plan:
> >>>> getX() returns int
> >>>> getXEnum() returns enum
> >>>> setX(int)
> >>>> setX(enum)
> >>>>
> >>>> I will also take a look at bug 59907 (client anchor enum)
> >>>>
> >>>> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk>
> >> wrote:
> >>>>
> >>>>> Javen, any thoughts on this one?
> >>>>>
> >>>>> On 13/09/16 12:14, Dominik Stadler wrote:
> >>>>>> Hi,
> >>>>>>
> >>&g

RE: [VOTE] Apache POI 3.15 (RC2)

2016-09-15 Thread Allison, Timothy B.
I'm finally taking a look at the new exceptions from the reports.

Most of the new exceptions seem to be on attachments within ppt.  We recently 
changed how we handle embedded ole-wrapped attachments in ppt, and we're 
discovering new embedded file types. [1]

Next...to look at the content report...

[1] https://issues.apache.org/jira/browse/TIKA-2079

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org



Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-15 Thread Dominik Stadler
Hi,

The mem-leak patch looks good and sane!

I am still not sure how they end up with such a large amount of allocated
memory for one file, but it is surely better to not keep the buffers if we
do not need the special handling during close() anyway.

I have some minor modifications/simplifications around these statements
that I will apply post-release

Dominik.

On Thu, Sep 15, 2016 at 2:01 PM, Allison, Timothy B. <talli...@mitre.org>
wrote:

> >* I'll take a look at the patch on TIKA-2058, if it's low-risk it can go
> in
> I committed Luis Filipe Nassif's patch last night (BUG 60140).  Please do
> take a look to make sure the change doesn't cause any unforeseen problems.
>
> >> * I could do with input from those who use HSLF about whether to hold
> up another RC for the issue below.
> > I've already patched the HSLF issue yesterday
>
> Thank you, Andi!
>
>
> -Original Message-
> From: David North [mailto:dtn-...@corefiling.co.uk]
> Sent: Thursday, September 15, 2016 4:16 AM
> To: dev@poi.apache.org
> Subject: Re: [VOTE] Apache POI 3.15 (RC2)
>
> OK, current status:
>
> * I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in
> * I could do with input from those who use HSLF about whether to hold up
> another RC for the issue below.
>
> I may not have time to roll RC3 tonight; if not I'll do it tomorrow night
> which gives us all the weekend to try it out.
>
> Thanks,
> David
>
> On 14/09/16 21:39, Javen O'Neal wrote:
> > The HSLF footer text regression is still open.
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=60003
> > https://issues.apache.org/jira/browse/TIKA-2013
> >
> > On Sep 14, 2016 12:43 PM, "Dominik Stadler" <dominik.stad...@gmx.at>
> wrote:
> >
> >> Hi,
> >>
> >> I'd also rather keep it as is to not break it multiple times.
> >>
> >> Dominik.
> >>
> >> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal <javenon...@gmail.com>
> >> wrote:
> >>
> >>> CellValue#getCellType was changed to return an enum after the 3.14
> >> release.
> >>> I reverted that signature change in r1760607 (see bug 59791 comment
> 13).
> >>>
> >>> For bug 59907, I broke backwards compatibility for ClientAnchor
> >>> (both
> >> HSSF
> >>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and
> >>> included in POI 3.14 final) without the usual 2 release deprecation
> >>> warning. The question is do I restore the behavior of 3.13 (breaking
> >>> code a second
> >> time
> >>> for anyone who upgraded their code to 3.14, and a third time
> >>> whenever we retire the int code), or do we leave it as is and ask
> >>> users to upgrade to the enum getter now?
> >>>
> >>> Looking at the code example from bug 59907 comment 1, the fix for
> >>> them is
> >>> simple: delete ".getValue()".
> >>>
> >>> On Sep 13, 2016 09:06, "Javen O'Neal" <javenon...@gmail.com> wrote:
> >>>
> >>>> I will commit a fix for this today with the goal for backwards
> >>>> compatibility.
> >>>>
> >>>> Here's the plan:
> >>>> getX() returns int
> >>>> getXEnum() returns enum
> >>>> setX(int)
> >>>> setX(enum)
> >>>>
> >>>> I will also take a look at bug 59907 (client anchor enum)
> >>>>
> >>>> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk>
> >> wrote:
> >>>>
> >>>>> Javen, any thoughts on this one?
> >>>>>
> >>>>> On 13/09/16 12:14, Dominik Stadler wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I really hate to delay this further, but unfortunately we have a
> >>> similar
> >>>>>> problem in class CellValue as we tried to fix in Cell in RC2, the
> >>>>>> getCellType() is now an enum whereas it was an int before, so
> >>> something
> >>>>>> like the following in user-code does break in POI 3.15:
> >>>>>>
> >>>>>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet,
> >>>>>> line);
> >>>>>>
> >>>>>> switch (cellValue.getCellType()) {
> >>>>>> case Cell.CELL_TYPE_STRING:
> >>>>>>
> >>>>>>
>

RE: [VOTE] Apache POI 3.15 (RC2)

2016-09-15 Thread Allison, Timothy B.
>* I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in
I committed Luis Filipe Nassif's patch last night (BUG 60140).  Please do take 
a look to make sure the change doesn't cause any unforeseen problems.

>> * I could do with input from those who use HSLF about whether to hold up 
>> another RC for the issue below.
> I've already patched the HSLF issue yesterday

Thank you, Andi!


-Original Message-
From: David North [mailto:dtn-...@corefiling.co.uk] 
Sent: Thursday, September 15, 2016 4:16 AM
To: dev@poi.apache.org
Subject: Re: [VOTE] Apache POI 3.15 (RC2)

OK, current status:

* I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in
* I could do with input from those who use HSLF about whether to hold up 
another RC for the issue below.

I may not have time to roll RC3 tonight; if not I'll do it tomorrow night which 
gives us all the weekend to try it out.

Thanks,
David

On 14/09/16 21:39, Javen O'Neal wrote:
> The HSLF footer text regression is still open.
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60003
> https://issues.apache.org/jira/browse/TIKA-2013
> 
> On Sep 14, 2016 12:43 PM, "Dominik Stadler" <dominik.stad...@gmx.at> wrote:
> 
>> Hi,
>>
>> I'd also rather keep it as is to not break it multiple times.
>>
>> Dominik.
>>
>> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal <javenon...@gmail.com>
>> wrote:
>>
>>> CellValue#getCellType was changed to return an enum after the 3.14
>> release.
>>> I reverted that signature change in r1760607 (see bug 59791 comment 13).
>>>
>>> For bug 59907, I broke backwards compatibility for ClientAnchor 
>>> (both
>> HSSF
>>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and 
>>> included in POI 3.14 final) without the usual 2 release deprecation 
>>> warning. The question is do I restore the behavior of 3.13 (breaking 
>>> code a second
>> time
>>> for anyone who upgraded their code to 3.14, and a third time 
>>> whenever we retire the int code), or do we leave it as is and ask 
>>> users to upgrade to the enum getter now?
>>>
>>> Looking at the code example from bug 59907 comment 1, the fix for 
>>> them is
>>> simple: delete ".getValue()".
>>>
>>> On Sep 13, 2016 09:06, "Javen O'Neal" <javenon...@gmail.com> wrote:
>>>
>>>> I will commit a fix for this today with the goal for backwards 
>>>> compatibility.
>>>>
>>>> Here's the plan:
>>>> getX() returns int
>>>> getXEnum() returns enum
>>>> setX(int)
>>>> setX(enum)
>>>>
>>>> I will also take a look at bug 59907 (client anchor enum)
>>>>
>>>> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk>
>> wrote:
>>>>
>>>>> Javen, any thoughts on this one?
>>>>>
>>>>> On 13/09/16 12:14, Dominik Stadler wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I really hate to delay this further, but unfortunately we have a
>>> similar
>>>>>> problem in class CellValue as we tried to fix in Cell in RC2, the
>>>>>> getCellType() is now an enum whereas it was an int before, so
>>> something
>>>>>> like the following in user-code does break in POI 3.15:
>>>>>>
>>>>>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, 
>>>>>> line);
>>>>>>
>>>>>> switch (cellValue.getCellType()) {
>>>>>> case Cell.CELL_TYPE_STRING:
>>>>>>
>>>>>>
>>>>>> I am sorry that I did not see this earlier but this can lead to 
>>>>>> the
>>> same
>>>>>> incompatibility as we had in Cell before.
>>>>>>
>>>>>> Dominik.
>>>>>>
>>>>>> On Sun, Sep 11, 2016 at 9:46 PM, David North <dno...@apache.org>
>>> wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> My apologies for going AWOL in the middle of the last release
>>> attempt.
>>>>> I
>>>>>>> didn't anticipate that we'd find problems in review twice in a 
>>>>>>> row,
>>> and
>>>>>>> things have been very busy for me at work lately. However, I've 
>>>>>>> now rolled a second RC for 3.1

Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-15 Thread kiwiwings
David North wrote
> * I could do with input from those who use HSLF about whether to hold up
> another RC for the issue below.

I've already patched the HSLF issue yesterday, based on the placeholder
being a metroblob shape,
but I wanted to think about it, if this is really a good idea or if a
different indicator can be used, e.g. the placeholder only containing a
predefined field.

Regardless of the solution, I don't think, this is necessary to be fixed for
the final, as it simply doesn't show up in the PPT and is only nice-to-have
metadata.


David North wrote
> I may not have time to roll RC3 tonight ...

As we have elapsed the anniversary date, we don't need to rush it now ...

Andi



--
View this message in context: 
http://apache-poi.1045710.n5.nabble.com/VOTE-Apache-POI-3-15-RC2-tp5724676p5724770.html
Sent from the POI - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org



Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-15 Thread David North
OK, current status:

* I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in
* I could do with input from those who use HSLF about whether to hold up
another RC for the issue below.

I may not have time to roll RC3 tonight; if not I'll do it tomorrow
night which gives us all the weekend to try it out.

Thanks,
David

On 14/09/16 21:39, Javen O'Neal wrote:
> The HSLF footer text regression is still open.
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60003
> https://issues.apache.org/jira/browse/TIKA-2013
> 
> On Sep 14, 2016 12:43 PM, "Dominik Stadler"  wrote:
> 
>> Hi,
>>
>> I'd also rather keep it as is to not break it multiple times.
>>
>> Dominik.
>>
>> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal 
>> wrote:
>>
>>> CellValue#getCellType was changed to return an enum after the 3.14
>> release.
>>> I reverted that signature change in r1760607 (see bug 59791 comment 13).
>>>
>>> For bug 59907, I broke backwards compatibility for ClientAnchor (both
>> HSSF
>>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in
>>> POI 3.14 final) without the usual 2 release deprecation warning. The
>>> question is do I restore the behavior of 3.13 (breaking code a second
>> time
>>> for anyone who upgraded their code to 3.14, and a third time whenever we
>>> retire the int code), or do we leave it as is and ask users to upgrade to
>>> the enum getter now?
>>>
>>> Looking at the code example from bug 59907 comment 1, the fix for them is
>>> simple: delete ".getValue()".
>>>
>>> On Sep 13, 2016 09:06, "Javen O'Neal"  wrote:
>>>
 I will commit a fix for this today with the goal for backwards
 compatibility.

 Here's the plan:
 getX() returns int
 getXEnum() returns enum
 setX(int)
 setX(enum)

 I will also take a look at bug 59907 (client anchor enum)

 On Sep 13, 2016 6:58 AM, "David North" 
>> wrote:

> Javen, any thoughts on this one?
>
> On 13/09/16 12:14, Dominik Stadler wrote:
>> Hi,
>>
>> I really hate to delay this further, but unfortunately we have a
>>> similar
>> problem in class CellValue as we tried to fix in Cell in RC2, the
>> getCellType() is now an enum whereas it was an int before, so
>>> something
>> like the following in user-code does break in POI 3.15:
>>
>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
>>
>> switch (cellValue.getCellType()) {
>> case Cell.CELL_TYPE_STRING:
>>
>>
>> I am sorry that I did not see this earlier but this can lead to the
>>> same
>> incompatibility as we had in Cell before.
>>
>> Dominik.
>>
>> On Sun, Sep 11, 2016 at 9:46 PM, David North 
>>> wrote:
>>
>>> Hi everyone,
>>>
>>> My apologies for going AWOL in the middle of the last release
>>> attempt.
> I
>>> didn't anticipate that we'd find problems in review twice in a row,
>>> and
>>> things have been very busy for me at work lately. However, I've now
>>> rolled a second RC for 3.15.
>>>
>>> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
>>>
>>> Areas to review:
>>>
>>> * Does it work?
>>> * Are the sigs and hashes valid?
>>> * Have the issues with the last RC been fixed?
>>> * Are the release notes now in good shape?
>>>
>>> The vote starts now and ends at 20:55 BST on Tuesday 13 September
>>> 2016.
>>>
>>> Here is my +1.
>>>
>>> After this release is done, I'll try and find some time to profile
>>> the
>>> build & tests - 15 minutes is quite a wait on an SSD (it's possible
>>> we
>>> might want some multi-threaded options on the tests).
>>>
>>> Thanks,
>>>
>>> --
>>> David North | www.dnorth.net
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>
>>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org



Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-14 Thread Javen O'Neal
The HSLF footer text regression is still open.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60003
https://issues.apache.org/jira/browse/TIKA-2013

On Sep 14, 2016 12:43 PM, "Dominik Stadler"  wrote:

> Hi,
>
> I'd also rather keep it as is to not break it multiple times.
>
> Dominik.
>
> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal 
> wrote:
>
> > CellValue#getCellType was changed to return an enum after the 3.14
> release.
> > I reverted that signature change in r1760607 (see bug 59791 comment 13).
> >
> > For bug 59907, I broke backwards compatibility for ClientAnchor (both
> HSSF
> > and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in
> > POI 3.14 final) without the usual 2 release deprecation warning. The
> > question is do I restore the behavior of 3.13 (breaking code a second
> time
> > for anyone who upgraded their code to 3.14, and a third time whenever we
> > retire the int code), or do we leave it as is and ask users to upgrade to
> > the enum getter now?
> >
> > Looking at the code example from bug 59907 comment 1, the fix for them is
> > simple: delete ".getValue()".
> >
> > On Sep 13, 2016 09:06, "Javen O'Neal"  wrote:
> >
> > > I will commit a fix for this today with the goal for backwards
> > > compatibility.
> > >
> > > Here's the plan:
> > > getX() returns int
> > > getXEnum() returns enum
> > > setX(int)
> > > setX(enum)
> > >
> > > I will also take a look at bug 59907 (client anchor enum)
> > >
> > > On Sep 13, 2016 6:58 AM, "David North" 
> wrote:
> > >
> > >> Javen, any thoughts on this one?
> > >>
> > >> On 13/09/16 12:14, Dominik Stadler wrote:
> > >> > Hi,
> > >> >
> > >> > I really hate to delay this further, but unfortunately we have a
> > similar
> > >> > problem in class CellValue as we tried to fix in Cell in RC2, the
> > >> > getCellType() is now an enum whereas it was an int before, so
> > something
> > >> > like the following in user-code does break in POI 3.15:
> > >> >
> > >> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
> > >> >
> > >> > switch (cellValue.getCellType()) {
> > >> > case Cell.CELL_TYPE_STRING:
> > >> >
> > >> >
> > >> > I am sorry that I did not see this earlier but this can lead to the
> > same
> > >> > incompatibility as we had in Cell before.
> > >> >
> > >> > Dominik.
> > >> >
> > >> > On Sun, Sep 11, 2016 at 9:46 PM, David North 
> > wrote:
> > >> >
> > >> >> Hi everyone,
> > >> >>
> > >> >> My apologies for going AWOL in the middle of the last release
> > attempt.
> > >> I
> > >> >> didn't anticipate that we'd find problems in review twice in a row,
> > and
> > >> >> things have been very busy for me at work lately. However, I've now
> > >> >> rolled a second RC for 3.15.
> > >> >>
> > >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
> > >> >>
> > >> >> Areas to review:
> > >> >>
> > >> >> * Does it work?
> > >> >> * Are the sigs and hashes valid?
> > >> >> * Have the issues with the last RC been fixed?
> > >> >> * Are the release notes now in good shape?
> > >> >>
> > >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September
> > 2016.
> > >> >>
> > >> >> Here is my +1.
> > >> >>
> > >> >> After this release is done, I'll try and find some time to profile
> > the
> > >> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible
> > we
> > >> >> might want some multi-threaded options on the tests).
> > >> >>
> > >> >> Thanks,
> > >> >>
> > >> >> --
> > >> >> David North | www.dnorth.net
> > >> >>
> > >> >>
> > >> >
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> > >> For additional commands, e-mail: dev-h...@poi.apache.org
> > >>
> > >>
> >
>


Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-14 Thread Dominik Stadler
Hi,

I'd also rather keep it as is to not break it multiple times.

Dominik.

On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal  wrote:

> CellValue#getCellType was changed to return an enum after the 3.14 release.
> I reverted that signature change in r1760607 (see bug 59791 comment 13).
>
> For bug 59907, I broke backwards compatibility for ClientAnchor (both HSSF
> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in
> POI 3.14 final) without the usual 2 release deprecation warning. The
> question is do I restore the behavior of 3.13 (breaking code a second time
> for anyone who upgraded their code to 3.14, and a third time whenever we
> retire the int code), or do we leave it as is and ask users to upgrade to
> the enum getter now?
>
> Looking at the code example from bug 59907 comment 1, the fix for them is
> simple: delete ".getValue()".
>
> On Sep 13, 2016 09:06, "Javen O'Neal"  wrote:
>
> > I will commit a fix for this today with the goal for backwards
> > compatibility.
> >
> > Here's the plan:
> > getX() returns int
> > getXEnum() returns enum
> > setX(int)
> > setX(enum)
> >
> > I will also take a look at bug 59907 (client anchor enum)
> >
> > On Sep 13, 2016 6:58 AM, "David North"  wrote:
> >
> >> Javen, any thoughts on this one?
> >>
> >> On 13/09/16 12:14, Dominik Stadler wrote:
> >> > Hi,
> >> >
> >> > I really hate to delay this further, but unfortunately we have a
> similar
> >> > problem in class CellValue as we tried to fix in Cell in RC2, the
> >> > getCellType() is now an enum whereas it was an int before, so
> something
> >> > like the following in user-code does break in POI 3.15:
> >> >
> >> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
> >> >
> >> > switch (cellValue.getCellType()) {
> >> > case Cell.CELL_TYPE_STRING:
> >> >
> >> >
> >> > I am sorry that I did not see this earlier but this can lead to the
> same
> >> > incompatibility as we had in Cell before.
> >> >
> >> > Dominik.
> >> >
> >> > On Sun, Sep 11, 2016 at 9:46 PM, David North 
> wrote:
> >> >
> >> >> Hi everyone,
> >> >>
> >> >> My apologies for going AWOL in the middle of the last release
> attempt.
> >> I
> >> >> didn't anticipate that we'd find problems in review twice in a row,
> and
> >> >> things have been very busy for me at work lately. However, I've now
> >> >> rolled a second RC for 3.15.
> >> >>
> >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
> >> >>
> >> >> Areas to review:
> >> >>
> >> >> * Does it work?
> >> >> * Are the sigs and hashes valid?
> >> >> * Have the issues with the last RC been fixed?
> >> >> * Are the release notes now in good shape?
> >> >>
> >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September
> 2016.
> >> >>
> >> >> Here is my +1.
> >> >>
> >> >> After this release is done, I'll try and find some time to profile
> the
> >> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible
> we
> >> >> might want some multi-threaded options on the tests).
> >> >>
> >> >> Thanks,
> >> >>
> >> >> --
> >> >> David North | www.dnorth.net
> >> >>
> >> >>
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> >> For additional commands, e-mail: dev-h...@poi.apache.org
> >>
> >>
>


Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-14 Thread Dominik Stadler
Hi,

I would rather look at using some tools like
https://github.com/siom79/japicmp on the CI machine and check the output on
a regular basis or fail the build if there are incompatible changes. This
way we do not rely on having unit-tests for a method and the old source
often will not compile any more with newer code for arbitrary
reasonshttps://bz.apache.org/bugzilla/show_bug.cgi?id=60134.

I have created https://bz.apache.org/bugzilla/show_bug.cgi?id=60134 to
track this idea.

Dominik.

On Wed, Sep 14, 2016 at 2:27 AM, Javen O'Neal  wrote:

> Could we do some checks for backwards compatibility? We need to test an
> application written for a previous version of POI that exercises most or
> all of the features, and what better than to use the unit tests from a
> previous release plus the latest source code? This will include false
> positives such as removal and rename of deprecated classes and methods.
>
> $ svn co https://svn.apache.org/repos/asf/tag/REL_3_15_FINAL
> $ cd REL_3_15_FINAL
> $ svn up -r1732982 src/testcases src/ooxml/testcases
> src/scratchpad/testcases
> $ ant clean jenkins
>
> This doesn't compile due to deletion of deprecated features and any
> backwards incompatibilities.
>
> Is there a better way of doing this?
>
> On Sep 13, 2016 09:06, "Javen O'Neal"  wrote:
>
> > I will commit a fix for this today with the goal for backwards
> > compatibility.
> >
> > Here's the plan:
> > getX() returns int
> > getXEnum() returns enum
> > setX(int)
> > setX(enum)
> >
> > I will also take a look at bug 59907 (client anchor enum)
> >
> > On Sep 13, 2016 6:58 AM, "David North"  wrote:
> >
> >> Javen, any thoughts on this one?
> >>
> >> On 13/09/16 12:14, Dominik Stadler wrote:
> >> > Hi,
> >> >
> >> > I really hate to delay this further, but unfortunately we have a
> similar
> >> > problem in class CellValue as we tried to fix in Cell in RC2, the
> >> > getCellType() is now an enum whereas it was an int before, so
> something
> >> > like the following in user-code does break in POI 3.15:
> >> >
> >> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
> >> >
> >> > switch (cellValue.getCellType()) {
> >> > case Cell.CELL_TYPE_STRING:
> >> >
> >> >
> >> > I am sorry that I did not see this earlier but this can lead to the
> same
> >> > incompatibility as we had in Cell before.
> >> >
> >> > Dominik.
> >> >
> >> > On Sun, Sep 11, 2016 at 9:46 PM, David North 
> wrote:
> >> >
> >> >> Hi everyone,
> >> >>
> >> >> My apologies for going AWOL in the middle of the last release
> attempt.
> >> I
> >> >> didn't anticipate that we'd find problems in review twice in a row,
> and
> >> >> things have been very busy for me at work lately. However, I've now
> >> >> rolled a second RC for 3.15.
> >> >>
> >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
> >> >>
> >> >> Areas to review:
> >> >>
> >> >> * Does it work?
> >> >> * Are the sigs and hashes valid?
> >> >> * Have the issues with the last RC been fixed?
> >> >> * Are the release notes now in good shape?
> >> >>
> >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September
> 2016.
> >> >>
> >> >> Here is my +1.
> >> >>
> >> >> After this release is done, I'll try and find some time to profile
> the
> >> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible
> we
> >> >> might want some multi-threaded options on the tests).
> >> >>
> >> >> Thanks,
> >> >>
> >> >> --
> >> >> David North | www.dnorth.net
> >> >>
> >> >>
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> >> For additional commands, e-mail: dev-h...@poi.apache.org
> >>
> >>
>


RE: [VOTE] Apache POI 3.15 (RC2)

2016-09-14 Thread Allison, Timothy B.
Regression results are here.  I haven't had a chance to look.  This compares 
Tika's trunk with poi 3.15-rc1 (? I think?) against 3.15-beta1 in Tika 1.13.  
Some differences might be changes at the Tika level.

I ran this against the full corpus so there are file formats we don't care 
about.

https://github.com/tballison/share/blob/master/tika_comparisons/reports_tika_20160904_dev.zip


RE: [VOTE] Apache POI 3.15 (RC2)

2016-09-14 Thread Allison, Timothy B.
All,
  On TIKA-2058 [1], Luis Filipe Nassif attached a patch for POI that _may_ 
solve a memory leak.  We haven't had a chance to test that it solves the 
problem.  The patch looks reasonable to me (it is very short), but I don't know 
enough about FileBackedDataSource to apply it responsibly.
  If anyone has a chance to look, it would be great to apply this before we 
respin.
  Thank you!

 Best,

 Tim
[1] https://issues.apache.org/jira/browse/TIKA-2058 
-Original Message-
From: David North [mailto:dtn-...@corefiling.co.uk] 
Sent: Tuesday, September 13, 2016 12:09 PM
To: POI Developers List <dev@poi.apache.org>
Subject: Re: [VOTE] Apache POI 3.15 (RC2)

Thanks - sounds good. I guess I'd better change my +1 to a -1 and try to build 
a fresh RC tomorrow night.

On 13/09/16 17:06, Javen O'Neal wrote:
> I will commit a fix for this today with the goal for backwards 
> compatibility.
> 
> Here's the plan:
> getX() returns int
> getXEnum() returns enum
> setX(int)
> setX(enum)
> 
> I will also take a look at bug 59907 (client anchor enum)
> 
> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk> wrote:
> 
>> Javen, any thoughts on this one?
>>
>> On 13/09/16 12:14, Dominik Stadler wrote:
>>> Hi,
>>>
>>> I really hate to delay this further, but unfortunately we have a 
>>> similar problem in class CellValue as we tried to fix in Cell in 
>>> RC2, the
>>> getCellType() is now an enum whereas it was an int before, so 
>>> something like the following in user-code does break in POI 3.15:
>>>
>>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
>>>
>>> switch (cellValue.getCellType()) {
>>> case Cell.CELL_TYPE_STRING:
>>>
>>>
>>> I am sorry that I did not see this earlier but this can lead to the 
>>> same incompatibility as we had in Cell before.
>>>
>>> Dominik.
>>>
>>> On Sun, Sep 11, 2016 at 9:46 PM, David North <dno...@apache.org> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> My apologies for going AWOL in the middle of the last release 
>>>> attempt. I didn't anticipate that we'd find problems in review 
>>>> twice in a row, and things have been very busy for me at work 
>>>> lately. However, I've now rolled a second RC for 3.15.
>>>>
>>>> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
>>>>
>>>> Areas to review:
>>>>
>>>> * Does it work?
>>>> * Are the sigs and hashes valid?
>>>> * Have the issues with the last RC been fixed?
>>>> * Are the release notes now in good shape?
>>>>
>>>> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016.
>>>>
>>>> Here is my +1.
>>>>
>>>> After this release is done, I'll try and find some time to profile 
>>>> the build & tests - 15 minutes is quite a wait on an SSD (it's 
>>>> possible we might want some multi-threaded options on the tests).
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>> David North | www.dnorth.net
>>>>
>>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional 
>> commands, e-mail: dev-h...@poi.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, 
e-mail: dev-h...@poi.apache.org



Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-14 Thread Javen O'Neal
I read through all the commits mentioned in the bugs that block bug 59836.
These changes, excluding ClientAnchor.getAnchorType(), were made after the
release of POI 3.14, so I could safely revert back to the original getter
behavior. I have left ClientAnchor.getAnchorType() returning AnchorType
enum and am ***hoping for some discussion on this before we start RC3.***

The commits I made span for reverting the other getters span r1760607 to
r1760641. Some of these commits are just javadoc, @deprecated, @since,
@Deprecated, @Internal, and @Removal changes.

***Please add the following*** to the release notes per r1737751 bug 59264
comment 4:

CellStyle#BORDER_HAIR and #BORDER_DOTTED were swapped to correctly reflect
the official names and to be consistent with BorderStyle enum. HAIR has
smaller dots than DOTTED

On Sep 13, 2016 19:23, "Javen O'Neal"  wrote:

> CellValue#getCellType was changed to return an enum after the 3.14
> release. I reverted that signature change in r1760607 (see bug 59791
> comment 13).
>
> For bug 59907, I broke backwards compatibility for ClientAnchor (both HSSF
> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in
> POI 3.14 final) without the usual 2 release deprecation warning. The
> question is do I restore the behavior of 3.13 (breaking code a second time
> for anyone who upgraded their code to 3.14, and a third time whenever we
> retire the int code), or do we leave it as is and ask users to upgrade to
> the enum getter now?
>
> Looking at the code example from bug 59907 comment 1, the fix for them is
> simple: delete ".getValue()".
>
> On Sep 13, 2016 09:06, "Javen O'Neal"  wrote:
>
>> I will commit a fix for this today with the goal for backwards
>> compatibility.
>>
>> Here's the plan:
>> getX() returns int
>> getXEnum() returns enum
>> setX(int)
>> setX(enum)
>>
>> I will also take a look at bug 59907 (client anchor enum)
>>
>> On Sep 13, 2016 6:58 AM, "David North"  wrote:
>>
>>> Javen, any thoughts on this one?
>>>
>>> On 13/09/16 12:14, Dominik Stadler wrote:
>>> > Hi,
>>> >
>>> > I really hate to delay this further, but unfortunately we have a
>>> similar
>>> > problem in class CellValue as we tried to fix in Cell in RC2, the
>>> > getCellType() is now an enum whereas it was an int before, so something
>>> > like the following in user-code does break in POI 3.15:
>>> >
>>> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
>>> >
>>> > switch (cellValue.getCellType()) {
>>> > case Cell.CELL_TYPE_STRING:
>>> >
>>> >
>>> > I am sorry that I did not see this earlier but this can lead to the
>>> same
>>> > incompatibility as we had in Cell before.
>>> >
>>> > Dominik.
>>> >
>>> > On Sun, Sep 11, 2016 at 9:46 PM, David North 
>>> wrote:
>>> >
>>> >> Hi everyone,
>>> >>
>>> >> My apologies for going AWOL in the middle of the last release
>>> attempt. I
>>> >> didn't anticipate that we'd find problems in review twice in a row,
>>> and
>>> >> things have been very busy for me at work lately. However, I've now
>>> >> rolled a second RC for 3.15.
>>> >>
>>> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
>>> >>
>>> >> Areas to review:
>>> >>
>>> >> * Does it work?
>>> >> * Are the sigs and hashes valid?
>>> >> * Have the issues with the last RC been fixed?
>>> >> * Are the release notes now in good shape?
>>> >>
>>> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September
>>> 2016.
>>> >>
>>> >> Here is my +1.
>>> >>
>>> >> After this release is done, I'll try and find some time to profile the
>>> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible we
>>> >> might want some multi-threaded options on the tests).
>>> >>
>>> >> Thanks,
>>> >>
>>> >> --
>>> >> David North | www.dnorth.net
>>> >>
>>> >>
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>>> For additional commands, e-mail: dev-h...@poi.apache.org
>>>
>>>


Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-13 Thread Javen O'Neal
CellValue#getCellType was changed to return an enum after the 3.14 release.
I reverted that signature change in r1760607 (see bug 59791 comment 13).

For bug 59907, I broke backwards compatibility for ClientAnchor (both HSSF
and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in
POI 3.14 final) without the usual 2 release deprecation warning. The
question is do I restore the behavior of 3.13 (breaking code a second time
for anyone who upgraded their code to 3.14, and a third time whenever we
retire the int code), or do we leave it as is and ask users to upgrade to
the enum getter now?

Looking at the code example from bug 59907 comment 1, the fix for them is
simple: delete ".getValue()".

On Sep 13, 2016 09:06, "Javen O'Neal"  wrote:

> I will commit a fix for this today with the goal for backwards
> compatibility.
>
> Here's the plan:
> getX() returns int
> getXEnum() returns enum
> setX(int)
> setX(enum)
>
> I will also take a look at bug 59907 (client anchor enum)
>
> On Sep 13, 2016 6:58 AM, "David North"  wrote:
>
>> Javen, any thoughts on this one?
>>
>> On 13/09/16 12:14, Dominik Stadler wrote:
>> > Hi,
>> >
>> > I really hate to delay this further, but unfortunately we have a similar
>> > problem in class CellValue as we tried to fix in Cell in RC2, the
>> > getCellType() is now an enum whereas it was an int before, so something
>> > like the following in user-code does break in POI 3.15:
>> >
>> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
>> >
>> > switch (cellValue.getCellType()) {
>> > case Cell.CELL_TYPE_STRING:
>> >
>> >
>> > I am sorry that I did not see this earlier but this can lead to the same
>> > incompatibility as we had in Cell before.
>> >
>> > Dominik.
>> >
>> > On Sun, Sep 11, 2016 at 9:46 PM, David North  wrote:
>> >
>> >> Hi everyone,
>> >>
>> >> My apologies for going AWOL in the middle of the last release attempt.
>> I
>> >> didn't anticipate that we'd find problems in review twice in a row, and
>> >> things have been very busy for me at work lately. However, I've now
>> >> rolled a second RC for 3.15.
>> >>
>> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
>> >>
>> >> Areas to review:
>> >>
>> >> * Does it work?
>> >> * Are the sigs and hashes valid?
>> >> * Have the issues with the last RC been fixed?
>> >> * Are the release notes now in good shape?
>> >>
>> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016.
>> >>
>> >> Here is my +1.
>> >>
>> >> After this release is done, I'll try and find some time to profile the
>> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible we
>> >> might want some multi-threaded options on the tests).
>> >>
>> >> Thanks,
>> >>
>> >> --
>> >> David North | www.dnorth.net
>> >>
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>> For additional commands, e-mail: dev-h...@poi.apache.org
>>
>>


Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-13 Thread David North
Thanks - sounds good. I guess I'd better change my +1 to a -1 and try to
build a fresh RC tomorrow night.

On 13/09/16 17:06, Javen O'Neal wrote:
> I will commit a fix for this today with the goal for backwards
> compatibility.
> 
> Here's the plan:
> getX() returns int
> getXEnum() returns enum
> setX(int)
> setX(enum)
> 
> I will also take a look at bug 59907 (client anchor enum)
> 
> On Sep 13, 2016 6:58 AM, "David North"  wrote:
> 
>> Javen, any thoughts on this one?
>>
>> On 13/09/16 12:14, Dominik Stadler wrote:
>>> Hi,
>>>
>>> I really hate to delay this further, but unfortunately we have a similar
>>> problem in class CellValue as we tried to fix in Cell in RC2, the
>>> getCellType() is now an enum whereas it was an int before, so something
>>> like the following in user-code does break in POI 3.15:
>>>
>>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
>>>
>>> switch (cellValue.getCellType()) {
>>> case Cell.CELL_TYPE_STRING:
>>>
>>>
>>> I am sorry that I did not see this earlier but this can lead to the same
>>> incompatibility as we had in Cell before.
>>>
>>> Dominik.
>>>
>>> On Sun, Sep 11, 2016 at 9:46 PM, David North  wrote:
>>>
 Hi everyone,

 My apologies for going AWOL in the middle of the last release attempt. I
 didn't anticipate that we'd find problems in review twice in a row, and
 things have been very busy for me at work lately. However, I've now
 rolled a second RC for 3.15.

 https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/

 Areas to review:

 * Does it work?
 * Are the sigs and hashes valid?
 * Have the issues with the last RC been fixed?
 * Are the release notes now in good shape?

 The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016.

 Here is my +1.

 After this release is done, I'll try and find some time to profile the
 build & tests - 15 minutes is quite a wait on an SSD (it's possible we
 might want some multi-threaded options on the tests).

 Thanks,

 --
 David North | www.dnorth.net


>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>> For additional commands, e-mail: dev-h...@poi.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org



Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-13 Thread Javen O'Neal
I will commit a fix for this today with the goal for backwards
compatibility.

Here's the plan:
getX() returns int
getXEnum() returns enum
setX(int)
setX(enum)

I will also take a look at bug 59907 (client anchor enum)

On Sep 13, 2016 6:58 AM, "David North"  wrote:

> Javen, any thoughts on this one?
>
> On 13/09/16 12:14, Dominik Stadler wrote:
> > Hi,
> >
> > I really hate to delay this further, but unfortunately we have a similar
> > problem in class CellValue as we tried to fix in Cell in RC2, the
> > getCellType() is now an enum whereas it was an int before, so something
> > like the following in user-code does break in POI 3.15:
> >
> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
> >
> > switch (cellValue.getCellType()) {
> > case Cell.CELL_TYPE_STRING:
> >
> >
> > I am sorry that I did not see this earlier but this can lead to the same
> > incompatibility as we had in Cell before.
> >
> > Dominik.
> >
> > On Sun, Sep 11, 2016 at 9:46 PM, David North  wrote:
> >
> >> Hi everyone,
> >>
> >> My apologies for going AWOL in the middle of the last release attempt. I
> >> didn't anticipate that we'd find problems in review twice in a row, and
> >> things have been very busy for me at work lately. However, I've now
> >> rolled a second RC for 3.15.
> >>
> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
> >>
> >> Areas to review:
> >>
> >> * Does it work?
> >> * Are the sigs and hashes valid?
> >> * Have the issues with the last RC been fixed?
> >> * Are the release notes now in good shape?
> >>
> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016.
> >>
> >> Here is my +1.
> >>
> >> After this release is done, I'll try and find some time to profile the
> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible we
> >> might want some multi-threaded options on the tests).
> >>
> >> Thanks,
> >>
> >> --
> >> David North | www.dnorth.net
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>


Re: [VOTE] Apache POI 3.15 (RC2)

2016-09-13 Thread David North
Javen, any thoughts on this one?

On 13/09/16 12:14, Dominik Stadler wrote:
> Hi,
> 
> I really hate to delay this further, but unfortunately we have a similar
> problem in class CellValue as we tried to fix in Cell in RC2, the
> getCellType() is now an enum whereas it was an int before, so something
> like the following in user-code does break in POI 3.15:
> 
> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line);
> 
> switch (cellValue.getCellType()) {
> case Cell.CELL_TYPE_STRING:
> 
> 
> I am sorry that I did not see this earlier but this can lead to the same
> incompatibility as we had in Cell before.
> 
> Dominik.
> 
> On Sun, Sep 11, 2016 at 9:46 PM, David North  wrote:
> 
>> Hi everyone,
>>
>> My apologies for going AWOL in the middle of the last release attempt. I
>> didn't anticipate that we'd find problems in review twice in a row, and
>> things have been very busy for me at work lately. However, I've now
>> rolled a second RC for 3.15.
>>
>> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/
>>
>> Areas to review:
>>
>> * Does it work?
>> * Are the sigs and hashes valid?
>> * Have the issues with the last RC been fixed?
>> * Are the release notes now in good shape?
>>
>> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016.
>>
>> Here is my +1.
>>
>> After this release is done, I'll try and find some time to profile the
>> build & tests - 15 minutes is quite a wait on an SSD (it's possible we
>> might want some multi-threaded options on the tests).
>>
>> Thanks,
>>
>> --
>> David North | www.dnorth.net
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org



RE: [VOTE] Apache POI 3.15 (RC2)

2016-09-12 Thread Allison, Timothy B.
Kicked off regression tests.  Should have results by tomorrow.

-Original Message-
From: David North [mailto:dno...@apache.org] 
Sent: Sunday, September 11, 2016 3:47 PM
To: POI Developers List 
Subject: [VOTE] Apache POI 3.15 (RC2)

Hi everyone,

My apologies for going AWOL in the middle of the last release attempt. I didn't 
anticipate that we'd find problems in review twice in a row, and things have 
been very busy for me at work lately. However, I've now rolled a second RC for 
3.15.

https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/

Areas to review:

* Does it work?
* Are the sigs and hashes valid?
* Have the issues with the last RC been fixed?
* Are the release notes now in good shape?

The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016.

Here is my +1.

After this release is done, I'll try and find some time to profile the build & 
tests - 15 minutes is quite a wait on an SSD (it's possible we might want some 
multi-threaded options on the tests).

Thanks,

--
David North | www.dnorth.net