Request to backport "6296893: BMP Writer handles TopDown property incorrectly, for some of the compression types" into OpenJDK6

[Kelly O'Hair]

I did not mean to imply that OpenJDK6 changes cannot be made or there is some specific limit.
But it has just made sense in the past to try and stop changing the older releases in favor of the newer ones
at some point. I'm just wondering what to expect in the months ahead for OpenJDK6.

I will continue to approve any changes to OpenJDK6 that make sense and follow the rules we have tried
to have on this release.

So I'm trying to do a bit of a balancing act here, I want OpenJDK6 to be as stable and valuable as possible,
but a big part of that stability is trying to NOT change what does not need changing to avoid unwanted
regressions or surprising changes in behavior.

I am relying on many people to help me with these approvals when it's not obvious to me what to do.

-kto

On Sep 14, 2011, at 9:19 AM, Dr Andrew John Hughes wrote:

> On 20:41 Tue 13 Sep     , Phil Race wrote:
>> On 9/13/11 7:14 PM, Dr Andrew John Hughes wrote:
>>> On 17:43 Tue 13 Sep     , Kelly O'Hair wrote:
>>>> With Phil's comments. Then I approve.
>>>> 
>>>> These OpenJDK6 changes are tailing off, right?
>>>> Are there many more planned?
>>>> 
>>> No.  There are still about a hundred OpenJDK backports in IcedTea6 and
>>> we keep finding more.
>> 
>> Meaning this is already in icedtea ? But still ..
>> 
> 
> Yes, in HEAD but not yet in a release.
> 
> We try to upstream these backports as time allows, but this is starting to
> sound like you'd rather we didn't bother.  Is this the case?
> 
>>> OpenJDK6 is not going to disappear over night, especially when OpenJDK7
>>> is still largely untested and doesn't have a TCK available.
>> 
>> I don't know about "largely untested" as its been TCKed and its the RI 
>> for 7 ...
> 
> Sorry, I should clarify; I mean "largely untested" in comparison to
> OpenJDK6.  We can build binaries of OpenJDK7 for use in Fedora, RHEL,
> etc. but there is no TCK to verify them against and they've not really
> had any real-world testing as yet (we're not even two months in yet).
> This is compared with OpenJDK6 binaries which are TCKed for every new
> release and have had years of real-world usage.
> 
> As I'm sure you know, a source code base can't be TCKed.  Only
> binaries built from it can.  The snapshot used for the RI, which I
> presume is what you were referring to as having being TCKed, is
> already outdated and there will be differences between this and our
> builds, which will only increase with time.
> 
> In short, we can't start to consider dropping OpenJDK6 until 7 is an
> acceptable equivalent.  If Oracle want to see OpenJDK6 tail off, the
> TCK for 7 needs to be available under the same license as that for 6,
> so binaries of 7 can be tested.
> 
>> its mostly the same as the commercial product ... etc ..
> 
> I assume you mean the proprietary Oracle builds; there's nothing
> non-commercial about OpenJDK6/7.  I don't think some vague idea of
> "mostly the same" is good enough.  In my experience, it hasn't been
> in the past.
> 
> Our experience with OpenJDK6 vs. the proprietary JDK6, which had
> apparently passed the TCK, was that quite a number of failures were
> found with OpenJDK6 initially.  Given that this time the open
> derivative is closer to the proprietary build and has also apparently
> passed the TCK itself, things should be easier but I still don't think
> we can take it for granted that our binaries pass because the
> proprietary Oracle ones do.
> 
>> We stopped pro-actively backporting to "closed" 6 what seems like eons 
>> ago in favour of 7.
> 
> I don't see how this is relevant, given you're referring to a completely
> different product with different release cycles and support.
> 
> FWIW, Oracle, for the most part, have never pro-actively backported to
> OpenJDK6.  Bar a number of langtools and HotSpot changes, we've had to
> do pretty much all the work.
> 
>> 
>>> According to http://openjdk.java.net/census/#andrew, I'm listed as an
>>> OpenJDK6 reviewer.  Does this not mean I can approve such backports?
>> 
>> Reviewer means that the code is OK, but "individual engineer reviewing 
>> code" != "product/release owner"
> 
> Ok, so it's fairly meaningless then, as I've already been doing that for years.
> 
>> 
>> -phil.
>>>> -kto
>>>> 
> 
> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37