You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2010/09/03 12:48:24 UTC

[jira] Bulk change of issues targeting next milestone

There are 13 JIRAs listed as "fix for" the next milestone, but I don't
see any that are blockers for us publishing.

HARMONY-6638	[classlib][nio]Some Selector behavior fixed.
HARMONY-6620	[jdktools] Unit tests to test the functionality of the
javac/javaw binaries
HARMONY-6608	[classlib][archive]Unit tests to improve the coverage of
archive module
HARMONY-6585	[classlib][luni]HTTPURLConnectionImpl fails to store
Cookies set by the application
HARMONY-6584	[classlib][nio]SocketChannel should throw
AsynchronousCloseException if the channel is closed in another thread
HARMONY-6522	[classlib][luni] HttpURLConnection returns unread data from
previous chunked response
HARMONY-6521	[classlib][luni] HttpURLConnection.getResponseCode() hangs
on incomplete chunked response
HARMONY-6519	[classlib][archive] support .txt files are not text/plain files
HARMONY-6515	[classlib][regex] incorrect/confusing Pattern matching
behaviour
HARMONY-6505	H2 Database exposes Harmony JIT bug
HARMONY-6474	[classlib][concurrent]CopyOnWrite.equals throws
NullPointerException
HARMONY-6469	[classlib][luni]ObjectInputStream has unreached code.
HARMONY-6459	[classlib] [portlib] unix/hysock.c hysock_sockaddr_init6
has redundant code

I'm going to bulk change them to remove the next milestone target -- if
you see a blocker or regression here please say.

Regards,
Tim

Re: [jira] Bulk change of issues targeting next milestone

Posted by Tim Ellison <t....@gmail.com>.
On 03/Sep/2010 13:02, Christian Peter wrote:
> Am Freitag, den 03.09.2010, 11:48 +0100 schrieb Tim Ellison:
>> There are 13 JIRAs listed as "fix for" the next milestone, but I don't
>> see any that are blockers for us publishing.
>>
>> HARMONY-6638	[classlib][nio]Some Selector behavior fixed.
>> HARMONY-6620	[jdktools] Unit tests to test the functionality of the
>> javac/javaw binaries
>> HARMONY-6608	[classlib][archive]Unit tests to improve the coverage of
>> archive module
>> HARMONY-6585	[classlib][luni]HTTPURLConnectionImpl fails to store
>> Cookies set by the application
>> HARMONY-6584	[classlib][nio]SocketChannel should throw
>> AsynchronousCloseException if the channel is closed in another thread
>> HARMONY-6522	[classlib][luni] HttpURLConnection returns unread data from
>> previous chunked response
>> HARMONY-6521	[classlib][luni] HttpURLConnection.getResponseCode() hangs
>> on incomplete chunked response
>> HARMONY-6519	[classlib][archive] support .txt files are not text/plain files
>> HARMONY-6515	[classlib][regex] incorrect/confusing Pattern matching
>> behaviour
>> HARMONY-6505	H2 Database exposes Harmony JIT bug
>> HARMONY-6474	[classlib][concurrent]CopyOnWrite.equals throws
>> NullPointerException
>> HARMONY-6469	[classlib][luni]ObjectInputStream has unreached code.
>> HARMONY-6459	[classlib] [portlib] unix/hysock.c hysock_sockaddr_init6
>> has redundant code
>>
>> I'm going to bulk change them to remove the next milestone target -- if
>> you see a blocker or regression here please say.
>>
>> Regards,
>> Tim
> 
> Hi Tim,
> 
> I don't know if my opinion counts as well (since I'm no Harmony
> developer, only H2),

All opinions count!  but I'm still going to disagree with you :-)

> but I think the bug I created ("H2 Database exposes
> Harmony JIT bug") should be a blocker.

We are not claiming that the milestones are perfect, only that they are
the 'best so far' in terms of what the project has produced.  Hence, a
blocker for a milestone would be something that we have regressed (i.e.
functionality that used to work that we subsequently broke), or designs
in progress that have not reached sufficient quality.

In this case I think the JIT bug is not new for this milestone, and it
doesn't impact on the new functionality we have introduced in this
release.  For a new milestone, I believe the code we have in hand is
best so far.

> As long as it's not investigated, you don't know in which
> circumstances the bug can occur, and which other software does not
> work due to it.

I agree.  If somebody has any insight into this bug, and particularly if
there is an assessment of the impact (or a fix) please let us know.

Regards,
Tim

Re: [jira] Bulk change of issues targeting next milestone

Posted by Christian Peter <ch...@googlemail.com>.
Am Freitag, den 03.09.2010, 11:48 +0100 schrieb Tim Ellison:
> There are 13 JIRAs listed as "fix for" the next milestone, but I don't
> see any that are blockers for us publishing.
> 
> HARMONY-6638	[classlib][nio]Some Selector behavior fixed.
> HARMONY-6620	[jdktools] Unit tests to test the functionality of the
> javac/javaw binaries
> HARMONY-6608	[classlib][archive]Unit tests to improve the coverage of
> archive module
> HARMONY-6585	[classlib][luni]HTTPURLConnectionImpl fails to store
> Cookies set by the application
> HARMONY-6584	[classlib][nio]SocketChannel should throw
> AsynchronousCloseException if the channel is closed in another thread
> HARMONY-6522	[classlib][luni] HttpURLConnection returns unread data from
> previous chunked response
> HARMONY-6521	[classlib][luni] HttpURLConnection.getResponseCode() hangs
> on incomplete chunked response
> HARMONY-6519	[classlib][archive] support .txt files are not text/plain files
> HARMONY-6515	[classlib][regex] incorrect/confusing Pattern matching
> behaviour
> HARMONY-6505	H2 Database exposes Harmony JIT bug
> HARMONY-6474	[classlib][concurrent]CopyOnWrite.equals throws
> NullPointerException
> HARMONY-6469	[classlib][luni]ObjectInputStream has unreached code.
> HARMONY-6459	[classlib] [portlib] unix/hysock.c hysock_sockaddr_init6
> has redundant code
> 
> I'm going to bulk change them to remove the next milestone target -- if
> you see a blocker or regression here please say.
> 
> Regards,
> Tim

Hi Tim,

I don't know if my opinion counts as well (since I'm no Harmony
developer, only H2), but I think the bug I created ("H2 Database exposes
Harmony JIT bug") should be a blocker.

As long as it's not investigated, you don't know in which circumstances
the bug can occur, and which other software does not work due to it.

Regards

Christian Peter