[8u-communication] JDK 8u60 released today! (and 8u72 timeline)

[Rob McKenna]

Since moving to the new process[0] where a regular JDK 8 Update is 
released in parallel with a JDK 8 Critical Patch Update (CPU), it's 
impossible to share a true snapshot of the final JDK 8 Update forest 
until GA has occurred. That's due to the vulnerability fixes which need 
to be integrated into the update forest prior to GA. Such integrations 
are currently happening at the RDP2 milestone.

If you want to recreate the current state of a release in RDP2 (less 
vulnerability fixes) then you will need to maintain your own forest.

Thankfully the number of applicable fixes post-RDP2 should be relatively 
low. (2 in the case of your example [1]) Generally a simple hg export / 
import should be all that is required to take fixes from jdk8u and 
transplant them into your new forest.

	-Rob

[0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html
[1] 
https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%208u66%20and%20resolution%20%3D%20fixed%20and%20%20%22Resolved%20In%20Build%22%20not%20in%20%28b01%2C%20b02%29%20%20and%20%28labels%20is%20EMPTY%20or%20labels%20!%3D%20hgupdate-sync%29%20%20and%20level%20is%20EMPTY


On 07/09/15 20:15, Andrew Hughes wrote:
> ----- Original Message -----
>> Approved changesets are available in the always open forest so
>> reproducing the state of a post-rdp2 release shouldn't be very difficult.
>>
>> Any fixes that go into a release post-RDP2 will have a corresponding JBS
>> backport. If you search JBS for a fixVersion of 8uXX (and a resolved in
>> build value >= to the RDP2 build) you'll see a list of fixes approved
>> for that release.
>
> Ok, so let me see if I understand this correctly.
>
> If I want to re-create, say, jdk8u66-b03, I would have to check out
> jdk8u66-b02 from http://hg.openjdk.java.net/jdk8u/jdk8u and friends,
> then go through the OpenJDK bug database and find every bug that
> was fixed in jdk8u66-b03 (e.g. [0]), then find out what the original
> bug ID is for each one, then backport all the changesets?
>
> Then, for jdk8u66-b04, I have to do the same again and so on.
>
> This seems unnecessarily convoluted and prone to error. Why not just
> make the trees available as before?
>
> [0] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20status%20%3D%20Resolved%20AND%20%22Resolved%20In%20Build%22%20in%20%28b02%2C%20b03%29%20AND%20fixVersion%20%3D%208u66%20ORDER%20BY%20priority%20DESC
>
>>
>>      -Rob
>>
>> On 04/09/15 22:21, Omair Majid wrote:
>>> Hi Rob,
>>>
>>> * Rob McKenna <rob.mckenna at oracle.com> [2015-08-19 13:26]:
>>>> Some folks may be wondering how they get fixes pushed into 8u66 so
>>>> just to reiterate, all you have to do is follow the critical approval
>>>> process [1] and the maintainers will take care of the rest!
>>>
>>> I am hoping I am misreading or misinterpreting some of this because it
>>> sounds to me like you are saying that the community can't see what fixes
>>> a future 8uXY release contains until it is tagged and released on the
>>> day of the release (which coincides with the day of the CPU). What I
>>> understand is that we can still ask for changesets to be backported but
>>> we can't actually see/test/fix the 8u66 trees until a release is "done"?
>>> And the same will happen for the 8u72 release after this October so we
>>> can't see/test/fix what-really-is-8u72 ether after October?
>>>
>>> Is that right?
>>>
>>> Thanks,
>>> Omair
>>>
>>
>