Merging jdk9/hs and jdk9/dev

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Merging jdk9/hs and jdk9/dev

Mikael Vidstedt-3

All,

As you all know JDK 9 development is ramping down, and according to the JDK 9 release schedule [1] we are entering Ramp-down Phase 2 (RDP2) starting next week (March 16). While there is a small number of open issues it is reasonable to believe that the inflow of changes will approach zero over the next few days/weeks. Any changes going forward will effectively be for show stopper type bugs, and must as such be well tested and vetted before they are integrated.

Given the state we’re in with the release, and in line with earlier efforts to streamline our integration processes, we propose closing down jdk9/hs [2] and moving the remaining JDK 9 (hotspot) work directly to jdk9/dev [3]. In addition to a reduction in integration overhead, this will also shorten the lead times of getting changes into master in the final latency-sensitive phase of the release.

We propose that the final integration from jdk9/hs to jdk9/dev takes place on Thursday, March 23 after which jdk9/hs will be locked down/marked read-only to avoid any accidental integrations. Any work in flight would have to be rebased on jdk9/dev. Just like today, Hotspot integrations will still be made using JPRT.

Earlier consolidation projects have gone smoothly, but we will be keeping an extra eye on things and ask for your patience as we work through any issues.

Please let us know if you have any feedback or questions! If no serious objections have been raised by 15:00 UTC Thursday, March 16, we will go ahead with the forest consolidation as described.

[1] http://openjdk.java.net/projects/jdk9/
[2] http://hg.openjdk.java.net/jdk9/hs
[3] http://hg.openjdk.java.net/jdk9/dev

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Merging jdk9/hs and jdk9/dev

Mikael Vidstedt-3

Having heard no objections we’re looking to move forward with this.

Jesper, can you please provide some details on what the process is etc.?

Cheers,
Mikael


> On Mar 9, 2017, at 7:43 PM, Mikael Vidstedt <[hidden email]> wrote:
>
>
> All,
>
> As you all know JDK 9 development is ramping down, and according to the JDK 9 release schedule [1] we are entering Ramp-down Phase 2 (RDP2) starting next week (March 16). While there is a small number of open issues it is reasonable to believe that the inflow of changes will approach zero over the next few days/weeks. Any changes going forward will effectively be for show stopper type bugs, and must as such be well tested and vetted before they are integrated.
>
> Given the state we’re in with the release, and in line with earlier efforts to streamline our integration processes, we propose closing down jdk9/hs [2] and moving the remaining JDK 9 (hotspot) work directly to jdk9/dev [3]. In addition to a reduction in integration overhead, this will also shorten the lead times of getting changes into master in the final latency-sensitive phase of the release.
>
> We propose that the final integration from jdk9/hs to jdk9/dev takes place on Thursday, March 23 after which jdk9/hs will be locked down/marked read-only to avoid any accidental integrations. Any work in flight would have to be rebased on jdk9/dev. Just like today, Hotspot integrations will still be made using JPRT.
>
> Earlier consolidation projects have gone smoothly, but we will be keeping an extra eye on things and ask for your patience as we work through any issues.
>
> Please let us know if you have any feedback or questions! If no serious objections have been raised by 15:00 UTC Thursday, March 16, we will go ahead with the forest consolidation as described.
>
> [1] http://openjdk.java.net/projects/jdk9/
> [2] http://hg.openjdk.java.net/jdk9/hs
> [3] http://hg.openjdk.java.net/jdk9/dev
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Merging jdk9/hs and jdk9/dev

jesper.wilhelmsson
What will happen is the following:

1. On Thursday evening (PT) we will close jdk9/hs for pushes. This will be done before the Thursday nightly is started. To get some margin I'd say that if you haven't started your push before 5 pm PT, rebase and push to jdk9/dev instead.

2. On Friday I'll look at the nightly results and if there are no integration blockers I'll start the last PIT from jdk9/hs.
2.5. If there is anything blocking integration I will work with the relevant engineers to get the problem resolved and start the PIT asap.

3. Once the PIT is analysed and approved I'll push the last set of changes from jdk9/hs to jdk9/dev and ask for jdk9/hs to be made read only.

As mentioned below, going forward all pushes that modifies JDK 9 Hotspot code should go to jdk9/dev but should still use JPRT.
Nightly Hotspot testing will be moved to run on jdk9/dev.

Thanks,
/Jesper

> On 22 Mar 2017, at 17:21, Mikael Vidstedt <[hidden email]> wrote:
>
>
> Having heard no objections we’re looking to move forward with this.
>
> Jesper, can you please provide some details on what the process is etc.?
>
> Cheers,
> Mikael
>
>
>> On Mar 9, 2017, at 7:43 PM, Mikael Vidstedt <[hidden email]> wrote:
>>
>>
>> All,
>>
>> As you all know JDK 9 development is ramping down, and according to the JDK 9 release schedule [1] we are entering Ramp-down Phase 2 (RDP2) starting next week (March 16). While there is a small number of open issues it is reasonable to believe that the inflow of changes will approach zero over the next few days/weeks. Any changes going forward will effectively be for show stopper type bugs, and must as such be well tested and vetted before they are integrated.
>>
>> Given the state we’re in with the release, and in line with earlier efforts to streamline our integration processes, we propose closing down jdk9/hs [2] and moving the remaining JDK 9 (hotspot) work directly to jdk9/dev [3]. In addition to a reduction in integration overhead, this will also shorten the lead times of getting changes into master in the final latency-sensitive phase of the release.
>>
>> We propose that the final integration from jdk9/hs to jdk9/dev takes place on Thursday, March 23 after which jdk9/hs will be locked down/marked read-only to avoid any accidental integrations. Any work in flight would have to be rebased on jdk9/dev. Just like today, Hotspot integrations will still be made using JPRT.
>>
>> Earlier consolidation projects have gone smoothly, but we will be keeping an extra eye on things and ask for your patience as we work through any issues.
>>
>> Please let us know if you have any feedback or questions! If no serious objections have been raised by 15:00 UTC Thursday, March 16, we will go ahead with the forest consolidation as described.
>>
>> [1] http://openjdk.java.net/projects/jdk9/
>> [2] http://hg.openjdk.java.net/jdk9/hs
>> [3] http://hg.openjdk.java.net/jdk9/dev
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Merging jdk9/hs and jdk9/dev

Daniel D. Daugherty
The plan sounds wonderful.

When JDK9-hs is made read-only, can we also remove:

     http://hg.openjdk.java.net/jdk9/hs-rt

The last push to that repo was done on 2016.04.14 so we're coming
up on a year with the JDK9-hs-rt repo being read-only...

Dan

P.S.
http://hg.openjdk.java.net/jdk9/hs-gc has been read-only for longer
and http://hg.openjdk.java.net/jdk9/hs-comp has been read-only for
less time... Might want to retire those repos also...


On 3/22/17 11:01 AM, [hidden email] wrote:

> What will happen is the following:
>
> 1. On Thursday evening (PT) we will close jdk9/hs for pushes. This will be done before the Thursday nightly is started. To get some margin I'd say that if you haven't started your push before 5 pm PT, rebase and push to jdk9/dev instead.
>
> 2. On Friday I'll look at the nightly results and if there are no integration blockers I'll start the last PIT from jdk9/hs.
> 2.5. If there is anything blocking integration I will work with the relevant engineers to get the problem resolved and start the PIT asap.
>
> 3. Once the PIT is analysed and approved I'll push the last set of changes from jdk9/hs to jdk9/dev and ask for jdk9/hs to be made read only.
>
> As mentioned below, going forward all pushes that modifies JDK 9 Hotspot code should go to jdk9/dev but should still use JPRT.
> Nightly Hotspot testing will be moved to run on jdk9/dev.
>
> Thanks,
> /Jesper
>
>> On 22 Mar 2017, at 17:21, Mikael Vidstedt <[hidden email]> wrote:
>>
>>
>> Having heard no objections we’re looking to move forward with this.
>>
>> Jesper, can you please provide some details on what the process is etc.?
>>
>> Cheers,
>> Mikael
>>
>>
>>> On Mar 9, 2017, at 7:43 PM, Mikael Vidstedt <[hidden email]> wrote:
>>>
>>>
>>> All,
>>>
>>> As you all know JDK 9 development is ramping down, and according to the JDK 9 release schedule [1] we are entering Ramp-down Phase 2 (RDP2) starting next week (March 16). While there is a small number of open issues it is reasonable to believe that the inflow of changes will approach zero over the next few days/weeks. Any changes going forward will effectively be for show stopper type bugs, and must as such be well tested and vetted before they are integrated.
>>>
>>> Given the state we’re in with the release, and in line with earlier efforts to streamline our integration processes, we propose closing down jdk9/hs [2] and moving the remaining JDK 9 (hotspot) work directly to jdk9/dev [3]. In addition to a reduction in integration overhead, this will also shorten the lead times of getting changes into master in the final latency-sensitive phase of the release.
>>>
>>> We propose that the final integration from jdk9/hs to jdk9/dev takes place on Thursday, March 23 after which jdk9/hs will be locked down/marked read-only to avoid any accidental integrations. Any work in flight would have to be rebased on jdk9/dev. Just like today, Hotspot integrations will still be made using JPRT.
>>>
>>> Earlier consolidation projects have gone smoothly, but we will be keeping an extra eye on things and ask for your patience as we work through any issues.
>>>
>>> Please let us know if you have any feedback or questions! If no serious objections have been raised by 15:00 UTC Thursday, March 16, we will go ahead with the forest consolidation as described.
>>>
>>> [1] http://openjdk.java.net/projects/jdk9/
>>> [2] http://hg.openjdk.java.net/jdk9/hs
>>> [3] http://hg.openjdk.java.net/jdk9/dev
>>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Merging jdk9/hs and jdk9/dev

jesper.wilhelmsson
I think that is a good idea and I'll be happy to include removal of the three former team repos when sending the request to lock hs.

Thanks,
/Jesper

> On 22 Mar 2017, at 18:18, Daniel D. Daugherty <[hidden email]> wrote:
>
> The plan sounds wonderful.
>
> When JDK9-hs is made read-only, can we also remove:
>
>    http://hg.openjdk.java.net/jdk9/hs-rt
>
> The last push to that repo was done on 2016.04.14 so we're coming
> up on a year with the JDK9-hs-rt repo being read-only...
>
> Dan
>
> P.S.
> http://hg.openjdk.java.net/jdk9/hs-gc has been read-only for longer
> and http://hg.openjdk.java.net/jdk9/hs-comp has been read-only for
> less time... Might want to retire those repos also...
>
>
> On 3/22/17 11:01 AM, [hidden email] wrote:
>> What will happen is the following:
>>
>> 1. On Thursday evening (PT) we will close jdk9/hs for pushes. This will be done before the Thursday nightly is started. To get some margin I'd say that if you haven't started your push before 5 pm PT, rebase and push to jdk9/dev instead.
>>
>> 2. On Friday I'll look at the nightly results and if there are no integration blockers I'll start the last PIT from jdk9/hs.
>> 2.5. If there is anything blocking integration I will work with the relevant engineers to get the problem resolved and start the PIT asap.
>>
>> 3. Once the PIT is analysed and approved I'll push the last set of changes from jdk9/hs to jdk9/dev and ask for jdk9/hs to be made read only.
>>
>> As mentioned below, going forward all pushes that modifies JDK 9 Hotspot code should go to jdk9/dev but should still use JPRT.
>> Nightly Hotspot testing will be moved to run on jdk9/dev.
>>
>> Thanks,
>> /Jesper
>>
>>> On 22 Mar 2017, at 17:21, Mikael Vidstedt <[hidden email]> wrote:
>>>
>>>
>>> Having heard no objections we’re looking to move forward with this.
>>>
>>> Jesper, can you please provide some details on what the process is etc.?
>>>
>>> Cheers,
>>> Mikael
>>>
>>>
>>>> On Mar 9, 2017, at 7:43 PM, Mikael Vidstedt <[hidden email]> wrote:
>>>>
>>>>
>>>> All,
>>>>
>>>> As you all know JDK 9 development is ramping down, and according to the JDK 9 release schedule [1] we are entering Ramp-down Phase 2 (RDP2) starting next week (March 16). While there is a small number of open issues it is reasonable to believe that the inflow of changes will approach zero over the next few days/weeks. Any changes going forward will effectively be for show stopper type bugs, and must as such be well tested and vetted before they are integrated.
>>>>
>>>> Given the state we’re in with the release, and in line with earlier efforts to streamline our integration processes, we propose closing down jdk9/hs [2] and moving the remaining JDK 9 (hotspot) work directly to jdk9/dev [3]. In addition to a reduction in integration overhead, this will also shorten the lead times of getting changes into master in the final latency-sensitive phase of the release.
>>>>
>>>> We propose that the final integration from jdk9/hs to jdk9/dev takes place on Thursday, March 23 after which jdk9/hs will be locked down/marked read-only to avoid any accidental integrations. Any work in flight would have to be rebased on jdk9/dev. Just like today, Hotspot integrations will still be made using JPRT.
>>>>
>>>> Earlier consolidation projects have gone smoothly, but we will be keeping an extra eye on things and ask for your patience as we work through any issues.
>>>>
>>>> Please let us know if you have any feedback or questions! If no serious objections have been raised by 15:00 UTC Thursday, March 16, we will go ahead with the forest consolidation as described.
>>>>
>>>> [1] http://openjdk.java.net/projects/jdk9/
>>>> [2] http://hg.openjdk.java.net/jdk9/hs
>>>> [3] http://hg.openjdk.java.net/jdk9/dev
>>>>
>>
>

Loading...