harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jira] Bulk change of issues targeting next milestone
Date Fri, 03 Sep 2010 13:51:17 GMT
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.


View raw message