jdk9/hs is CLOSED

[Christian Thalinger]

> On May 12, 2016, at 11:34 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>>> The more interesting question is if Oracle’s rules should also apply to
>>> non-shared code changes to ports that Oracle does not maintain.
> 
> No, it does not apply to not-shared code. Jesper's statement is correct.
> It is internal Oracle's process related only to produces we support.
> We discussed this issue at the end of last year (for original FC date):
> 
> "One question is whether changes to platforms we do not build and test (specifically, aix/ppc and the open aarch64 port) must abide strictly by the FC rules, or if we can be more lenient in accepting and integrating such changes. General consensus is that given that we're not building/testing them, clean changes which do not impact us can be integrated.”

I vaguely remembered that.  Thanks for digging it up.

> 
> Regards,
> Vladimir
> 
> On 5/12/16 2:08 PM, Jesper Wilhelmsson wrote:
>> Den 12/5/16 kl. 21:39, skrev Christian Thalinger:
>>> 
>>>> On May 12, 2016, at 5:17 AM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com
>>>> <mailto:jesper.wilhelmsson at oracle.com>> wrote:
>>>> 
>>>> Den 12/5/16 kl. 16:52, skrev Andrew Haley:
>>>>> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote:
>>>>>> Den 12/5/16 kl. 16:10, skrev Andrew Haley:
>>>>>>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote:
>>>>>>>> FC means that no RFE/Features can be pushed without approval from the JDK 9
>>>>>>>> Release Team. The updated schedule was published to the OpenJDK community in
>>>>>>>> December last year by Mark Reinhold.
>>>>>>> 
>>>>>>> You're not helping very much.  Or rather, you're restating what I've
>>>>>>> heard already but I don't know what that means.  Is finishing off the
>>>>>>> compact string intrinsics for AArch64 a RFE/Feature or not?  I don't
>>>>>>> know.  As far as I'm concerned it's a work in progress, which started
>>>>>>> some time ago.
>>>>>> 
>>>>>> Do you have a JBS ID for this work?
>>>>> 
>>>>> I thought so, but I can't see it.  I've been tending to create ad-hoc
>>>>> bugs for each part of the work.  But the need for it is implied by JEP
>>>>> 254: Compact Strings.  So you're perhaps telling me that if I had
>>>>> known that it was necessary to get this done, I should have created
>>>>> one?
>>>> 
>>>> I was mainly looking for something to read to try to figure out if this is an
>>>> enhancement or a bug. From your description it could be either.
>>> 
>>> It’s an enhancement.  As far as I know Compact Strings works fine without
>>> compiler intrinsics; it’s just slow.
>> 
>> Thanks for clarifying that!
>> 
>>> The more interesting question is if Oracle’s rules should also apply to
>>> non-shared code changes to ports that Oracle does not maintain.
>> 
>> That's a very interesting question indeed! Part of the answer needs to be a definition of what is Oracle's rules and what is OpenJDK rules. As far as I know there are very little (if anything) defined
>> on the OpenJDK web regarding rules around pushes and how to work with bugs in JBS. I don't think the fact that we have a triage process is even mentioned anywhere.
>> 
>> Is the lack of documentation the same as no rules?
>> 
>> FC, RDP, ZBB etc? Are these defined outside Oracle? Do we expect OpenJDK contributors to respect these?
>> 
>> Anyhow, the fact remains that changes pushed to jdk9/hs after we have taken the snapshot will not get into jdk9/jdk9 before FC simply because we will not be able to integrate them in time. If this
>> matters or not, I don't know.
>> 
>> As I wrote in my first response:
>> 
>> "If you are changing code that is not supported by Oracle - i.e. code that we don't test in our internal testing, there should be no issues getting this code into jdk9/hs. However, if you want the
>> code to get into jdk9/jdk9 before FC you'd have to push asap. Once we take the snapshot to start PIT no more changes from jdk9/hs will make it to jdk9/jdk9 before FC."
>> 
>> /Jesper
>> 
>>> 
>>>> 
>>>> JEP 254 is clearly a new feature and as such should be integrated before FC.
>>>> It was integrated in November 2015. Is it a bug that the parts you are fixing
>>>> now doesn't work..? I don't know.
>>>> 
>>>> You will need a JBS ID to push your changes anyway so I suggest you create a
>>>> bug for this (and make it a "Bug"). If no-one complains and it passes triage
>>>> as a bug I guess it is a bug and then you can push it when the repo opens again.
>>>> 
>>>> /Jesper
>>>