From Alan.Bateman at oracle.com Mon Jan 2 09:28:38 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Jan 2017 09:28:38 +0000 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <47b08c87-8b9d-ac86-83c2-28726daec93f@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> <47b08c87-8b9d-ac86-83c2-28726daec93f@oracle.com> Message-ID: On 20/12/2016 23:54, joe darcy wrote: > Hello, > > Returning to this topic, after additional consideration, I still think > we should start JDK 10 by hg pull'ing changes in from JDK 9. In other > words, adopt a forward-port rather than back-port policy, at least for > the time being. > > Under this model, engineers with a fix that had to go into both JDK 9 > and JDK 10 would just push the fix into 9 and a separate periodic > process would sync the changes into 10. > > Comments? This make sense to me, esp. since I would expect most people will be focused on fixing issues in JDK 9 for the next month or two at least. If you can keep significant refactoring changes out of JDK 10 for a month or two then it will make it easier or course but that might not be possible. The main thing is that once something is decided then it needs to be widely communicated to avoid issues such as the same change pushed to both jdk9/dev and jdk10/jdk10 as different changesets. -Alan From mark.reinhold at oracle.com Wed Jan 25 23:34:00 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 25 Jan 2017 15:34:00 -0800 (PST) Subject: JDK 10 forests open for bug fixes and small enhancements Message-ID: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> The Mercurial forests for JDK 10 are now available: http://hg.openjdk.java.net/jdk10/jdk10 -- Master + dev (combined) http://hg.openjdk.java.net/jdk10/hs -- HotSpot http://hg.openjdk.java.net/jdk10/sandbox -- Sandbox http://hg.openjdk.java.net/jdk10/client -- Client libraries Corresponding -changes mailing lists have also been created. The main differences from the forests for JDK 9 are that there are fewer of them, and that the "dev" and master forests have been combined. Most committers should push directly into jdk10/jdk10 except when working on HotSpot, a branch in the sandbox forest, or the client libraries. As of today these forests are open for bug fixes and small enhancements. Many committers will continue to focus mainly on JDK 9 for the next few months so, for now, we'll semi-automatically pull changes from JDK 9 and merge them into JDK 10. This means that if you make a change in JDK 9 then you needn't do any extra work to get it into JDK 10, though if a merge conflict arises then you might be asked to help resolve it. For work that's new in JDK 10, please try to keep destabilizing changes to a minimum, for now, in order to reduce the overhead of the continuous merges from JDK 9. If you want to work on a destabilizing change for JDK 10 then consider starting that work in a sandbox branch. Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as usual, to target significant features. The JDK 10 forests have the same structure as the JDK 9 forests. The repository consolidation proposed in JEP 296 [1] might be implemented later in the release. In the (hopefully infrequent) event that a change in JDK 10 needs to be back-ported to JDK 9 we'll have to figure out how to handle the duplicate bug ids that will arise when a back-ported change is later merged forward into JDK 10. One solution may just be to disable the unique bug-id test in jcheck, on the assumption that existing social conventions adequately protect us from the pathological scenarios that are prevented by this test. Thoughts welcome ... - Mark [1] http://openjdk.java.net/jeps/296 [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From david.holmes at oracle.com Thu Jan 26 12:06:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jan 2017 22:06:03 +1000 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> Message-ID: <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> Hi Mark, Great to see this. However, it seems (understandably) what we have populated jdk10 forests with is slightly out-of-date with respect to current jdk9 forests. What is the automated process for getting any missing JDK 9 fixes into JDK 10? At present we can't push anything via JPRT because we get failures due to missing fixes. Thanks, David On 26/01/2017 9:34 AM, mark.reinhold at oracle.com wrote: > The Mercurial forests for JDK 10 are now available: > > http://hg.openjdk.java.net/jdk10/jdk10 -- Master + dev (combined) > http://hg.openjdk.java.net/jdk10/hs -- HotSpot > http://hg.openjdk.java.net/jdk10/sandbox -- Sandbox > http://hg.openjdk.java.net/jdk10/client -- Client libraries > > Corresponding -changes mailing lists have also been created. > > The main differences from the forests for JDK 9 are that there are fewer > of them, and that the "dev" and master forests have been combined. Most > committers should push directly into jdk10/jdk10 except when working on > HotSpot, a branch in the sandbox forest, or the client libraries. > > As of today these forests are open for bug fixes and small enhancements. > > Many committers will continue to focus mainly on JDK 9 for the next few > months so, for now, we'll semi-automatically pull changes from JDK 9 and > merge them into JDK 10. This means that if you make a change in JDK 9 > then you needn't do any extra work to get it into JDK 10, though if a > merge conflict arises then you might be asked to help resolve it. > > For work that's new in JDK 10, please try to keep destabilizing changes > to a minimum, for now, in order to reduce the overhead of the continuous > merges from JDK 9. If you want to work on a destabilizing change for > JDK 10 then consider starting that work in a sandbox branch. > > Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as > usual, to target significant features. > > The JDK 10 forests have the same structure as the JDK 9 forests. The > repository consolidation proposed in JEP 296 [1] might be implemented > later in the release. > > In the (hopefully infrequent) event that a change in JDK 10 needs to be > back-ported to JDK 9 we'll have to figure out how to handle the duplicate > bug ids that will arise when a back-ported change is later merged forward > into JDK 10. One solution may just be to disable the unique bug-id test > in jcheck, on the assumption that existing social conventions adequately > protect us from the pathological scenarios that are prevented by this > test. Thoughts welcome ... > > - Mark > > > [1] http://openjdk.java.net/jeps/296 > [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From tobias.hartmann at oracle.com Thu Jan 26 12:13:26 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 26 Jan 2017 13:13:26 +0100 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> Message-ID: <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> Hi David, On 26.01.2017 13:06, David Holmes wrote: > Hi Mark, > > Great to see this. However, it seems (understandably) what we have populated jdk10 forests with is slightly out-of-date with respect to current jdk9 forests. What is the automated process for getting any missing JDK 9 fixes into JDK 10? At present we can't push anything via JPRT because we get failures due to missing fixes. Isn't this just because those changes are not yet in jdk9/dev but only in hs and jdk10 is synced with jdk9/dev? Best regards, Tobias > > Thanks, > David > > On 26/01/2017 9:34 AM, mark.reinhold at oracle.com wrote: >> The Mercurial forests for JDK 10 are now available: >> >> http://hg.openjdk.java.net/jdk10/jdk10 -- Master + dev (combined) >> http://hg.openjdk.java.net/jdk10/hs -- HotSpot >> http://hg.openjdk.java.net/jdk10/sandbox -- Sandbox >> http://hg.openjdk.java.net/jdk10/client -- Client libraries >> >> Corresponding -changes mailing lists have also been created. >> >> The main differences from the forests for JDK 9 are that there are fewer >> of them, and that the "dev" and master forests have been combined. Most >> committers should push directly into jdk10/jdk10 except when working on >> HotSpot, a branch in the sandbox forest, or the client libraries. >> >> As of today these forests are open for bug fixes and small enhancements. >> >> Many committers will continue to focus mainly on JDK 9 for the next few >> months so, for now, we'll semi-automatically pull changes from JDK 9 and >> merge them into JDK 10. This means that if you make a change in JDK 9 >> then you needn't do any extra work to get it into JDK 10, though if a >> merge conflict arises then you might be asked to help resolve it. >> >> For work that's new in JDK 10, please try to keep destabilizing changes >> to a minimum, for now, in order to reduce the overhead of the continuous >> merges from JDK 9. If you want to work on a destabilizing change for >> JDK 10 then consider starting that work in a sandbox branch. >> >> Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as >> usual, to target significant features. >> >> The JDK 10 forests have the same structure as the JDK 9 forests. The >> repository consolidation proposed in JEP 296 [1] might be implemented >> later in the release. >> >> In the (hopefully infrequent) event that a change in JDK 10 needs to be >> back-ported to JDK 9 we'll have to figure out how to handle the duplicate >> bug ids that will arise when a back-ported change is later merged forward >> into JDK 10. One solution may just be to disable the unique bug-id test >> in jcheck, on the assumption that existing social conventions adequately >> protect us from the pathological scenarios that are prevented by this >> test. Thoughts welcome ... >> >> - Mark >> >> >> [1] http://openjdk.java.net/jeps/296 >> [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> From david.holmes at oracle.com Thu Jan 26 12:18:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jan 2017 22:18:10 +1000 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> Message-ID: <21154e91-467f-aa86-629e-3602767ce52a@oracle.com> Hi Tobias, On 26/01/2017 10:13 PM, Tobias Hartmann wrote: > Hi David, > > On 26.01.2017 13:06, David Holmes wrote: >> Hi Mark, >> >> Great to see this. However, it seems (understandably) what we have populated jdk10 forests with is slightly out-of-date with respect to current jdk9 forests. What is the automated process for getting any missing JDK 9 fixes into JDK 10? At present we can't push anything via JPRT because we get failures due to missing fixes. > > Isn't this just because those changes are not yet in jdk9/dev but only in hs and jdk10 is synced with jdk9/dev? I don't know, that's what I am asking. :) We need the missing fixes to propagate through before we can actual submit via JPRT. But I would not have expected anything that causes a JPRT failure to have escaped from jdk9/hs to jdk9/dev. ?? Thanks, David > Best regards, > Tobias > >> >> Thanks, >> David >> >> On 26/01/2017 9:34 AM, mark.reinhold at oracle.com wrote: >>> The Mercurial forests for JDK 10 are now available: >>> >>> http://hg.openjdk.java.net/jdk10/jdk10 -- Master + dev (combined) >>> http://hg.openjdk.java.net/jdk10/hs -- HotSpot >>> http://hg.openjdk.java.net/jdk10/sandbox -- Sandbox >>> http://hg.openjdk.java.net/jdk10/client -- Client libraries >>> >>> Corresponding -changes mailing lists have also been created. >>> >>> The main differences from the forests for JDK 9 are that there are fewer >>> of them, and that the "dev" and master forests have been combined. Most >>> committers should push directly into jdk10/jdk10 except when working on >>> HotSpot, a branch in the sandbox forest, or the client libraries. >>> >>> As of today these forests are open for bug fixes and small enhancements. >>> >>> Many committers will continue to focus mainly on JDK 9 for the next few >>> months so, for now, we'll semi-automatically pull changes from JDK 9 and >>> merge them into JDK 10. This means that if you make a change in JDK 9 >>> then you needn't do any extra work to get it into JDK 10, though if a >>> merge conflict arises then you might be asked to help resolve it. >>> >>> For work that's new in JDK 10, please try to keep destabilizing changes >>> to a minimum, for now, in order to reduce the overhead of the continuous >>> merges from JDK 9. If you want to work on a destabilizing change for >>> JDK 10 then consider starting that work in a sandbox branch. >>> >>> Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as >>> usual, to target significant features. >>> >>> The JDK 10 forests have the same structure as the JDK 9 forests. The >>> repository consolidation proposed in JEP 296 [1] might be implemented >>> later in the release. >>> >>> In the (hopefully infrequent) event that a change in JDK 10 needs to be >>> back-ported to JDK 9 we'll have to figure out how to handle the duplicate >>> bug ids that will arise when a back-ported change is later merged forward >>> into JDK 10. One solution may just be to disable the unique bug-id test >>> in jcheck, on the assumption that existing social conventions adequately >>> protect us from the pathological scenarios that are prevented by this >>> test. Thoughts welcome ... >>> >>> - Mark >>> >>> >>> [1] http://openjdk.java.net/jeps/296 >>> [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>> From Alan.Bateman at oracle.com Thu Jan 26 12:31:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Jan 2017 12:31:53 +0000 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> Message-ID: On 26/01/2017 12:13, Tobias Hartmann wrote: > Hi David, > > On 26.01.2017 13:06, David Holmes wrote: >> Hi Mark, >> >> Great to see this. However, it seems (understandably) what we have populated jdk10 forests with is slightly out-of-date with respect to current jdk9 forests. What is the automated process for getting any missing JDK 9 fixes into JDK 10? At present we can't push anything via JPRT because we get failures due to missing fixes. > Isn't this just because those changes are not yet in jdk9/dev but only in hs and jdk10 is synced with jdk9/dev? > The jdk10 forests seem to be seeded with jdk-9+153, I suspect David is looking for changes are that backed up in jdk9/hs and haven't made it into a JDK 9 promoted build yet. -Alan From tobias.hartmann at oracle.com Thu Jan 26 12:32:32 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 26 Jan 2017 13:32:32 +0100 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <21154e91-467f-aa86-629e-3602767ce52a@oracle.com> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> <21154e91-467f-aa86-629e-3602767ce52a@oracle.com> Message-ID: On 26.01.2017 13:18, David Holmes wrote: > Hi Tobias, > > On 26/01/2017 10:13 PM, Tobias Hartmann wrote: >> Hi David, >> >> On 26.01.2017 13:06, David Holmes wrote: >>> Hi Mark, >>> >>> Great to see this. However, it seems (understandably) what we have populated jdk10 forests with is slightly out-of-date with respect to current jdk9 forests. What is the automated process for getting any missing JDK 9 fixes into JDK 10? At present we can't push anything via JPRT because we get failures due to missing fixes. >> >> Isn't this just because those changes are not yet in jdk9/dev but only in hs and jdk10 is synced with jdk9/dev? > > I don't know, that's what I am asking. :) We need the missing fixes to propagate through before we can actual submit via JPRT. > > But I would not have expected anything that causes a JPRT failure to have escaped from jdk9/hs to jdk9/dev. ?? Yes but that happened because these failures do not always show up. For example, JDK-8173391 and also JDK-8172010 you've mentioned on hotspot-dev. Best regards, Tobias > > Thanks, > David > >> Best regards, >> Tobias >> >>> >>> Thanks, >>> David >>> >>> On 26/01/2017 9:34 AM, mark.reinhold at oracle.com wrote: >>>> The Mercurial forests for JDK 10 are now available: >>>> >>>> http://hg.openjdk.java.net/jdk10/jdk10 -- Master + dev (combined) >>>> http://hg.openjdk.java.net/jdk10/hs -- HotSpot >>>> http://hg.openjdk.java.net/jdk10/sandbox -- Sandbox >>>> http://hg.openjdk.java.net/jdk10/client -- Client libraries >>>> >>>> Corresponding -changes mailing lists have also been created. >>>> >>>> The main differences from the forests for JDK 9 are that there are fewer >>>> of them, and that the "dev" and master forests have been combined. Most >>>> committers should push directly into jdk10/jdk10 except when working on >>>> HotSpot, a branch in the sandbox forest, or the client libraries. >>>> >>>> As of today these forests are open for bug fixes and small enhancements. >>>> >>>> Many committers will continue to focus mainly on JDK 9 for the next few >>>> months so, for now, we'll semi-automatically pull changes from JDK 9 and >>>> merge them into JDK 10. This means that if you make a change in JDK 9 >>>> then you needn't do any extra work to get it into JDK 10, though if a >>>> merge conflict arises then you might be asked to help resolve it. >>>> >>>> For work that's new in JDK 10, please try to keep destabilizing changes >>>> to a minimum, for now, in order to reduce the overhead of the continuous >>>> merges from JDK 9. If you want to work on a destabilizing change for >>>> JDK 10 then consider starting that work in a sandbox branch. >>>> >>>> Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as >>>> usual, to target significant features. >>>> >>>> The JDK 10 forests have the same structure as the JDK 9 forests. The >>>> repository consolidation proposed in JEP 296 [1] might be implemented >>>> later in the release. >>>> >>>> In the (hopefully infrequent) event that a change in JDK 10 needs to be >>>> back-ported to JDK 9 we'll have to figure out how to handle the duplicate >>>> bug ids that will arise when a back-ported change is later merged forward >>>> into JDK 10. One solution may just be to disable the unique bug-id test >>>> in jcheck, on the assumption that existing social conventions adequately >>>> protect us from the pathological scenarios that are prevented by this >>>> test. Thoughts welcome ... >>>> >>>> - Mark >>>> >>>> >>>> [1] http://openjdk.java.net/jeps/296 >>>> [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>>> From philip.race at oracle.com Thu Jan 26 13:43:57 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 26 Jan 2017 05:43:57 -0800 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> Message-ID: <5889FD1D.7070004@oracle.com> So there is an expectation that 10-hs is seeded from 9-hs and so forth ? I guess not just for seeding, but on-going the sync will be from jdk9/jdk9 no matter what the destination forest. -phil.. On 1/26/17, 4:31 AM, Alan Bateman wrote: >> > The jdk10 forests seem to be seeded with jdk-9+153, I suspect David is > looking for changes are that backed up in jdk9/hs and haven't made it > into a JDK 9 promoted build yet. From jesper.wilhelmsson at oracle.com Thu Jan 26 16:12:20 2017 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 26 Jan 2017 17:12:20 +0100 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <5889FD1D.7070004@oracle.com> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> <5889FD1D.7070004@oracle.com> Message-ID: I'm not the decision maker here, but this is what was said in a meeting: The jdk10/jdk10 forest will sync with jdk9/dev. New changes in jdk9/dev is pulled into 10 this way. The process is planned to be made automatic using Mach 5 but initially Lana and I will be doing the integrations. jdk10/hs is a child of jdk10/dev. For changes to go from jdk9/hs to jdk10/hs they will have to go through 9/dev and 10/dev. This is assumed to take a while. Right now we only integrate 9/hs to 9/dev once a week, and at most we can crank that up to twice a week due to the rigorous testing requirements. Once we get Mach 5 support for HotSpot testing (running all the required VM tests) we can start integrating more often. HTH, /Jesper Den 26/1/17 kl. 14:43, skrev Philip Race: > So there is an expectation that 10-hs is seeded from 9-hs and so forth ? > I guess not just for seeding, but on-going the sync will be from jdk9/jdk9 > no matter what the destination forest. > > -phil.. > > > > On 1/26/17, 4:31 AM, Alan Bateman wrote: >>> >> The jdk10 forests seem to be seeded with jdk-9+153, I suspect David is >> looking for changes are that backed up in jdk9/hs and haven't made it into a >> JDK 9 promoted build yet. From david.holmes at oracle.com Thu Jan 26 21:08:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2017 07:08:35 +1000 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> <5889FD1D.7070004@oracle.com> Message-ID: <8d35b1c3-47bc-a11a-53e4-5f4dcb45df39@oracle.com> On 27/01/2017 2:12 AM, Jesper Wilhelmsson wrote: > I'm not the decision maker here, but this is what was said in a meeting: > > The jdk10/jdk10 forest will sync with jdk9/dev. New changes in jdk9/dev > is pulled into 10 this way. The process is planned to be made automatic > using Mach 5 but initially Lana and I will be doing the integrations. > > jdk10/hs is a child of jdk10/dev. For changes to go from jdk9/hs to > jdk10/hs they will have to go through 9/dev and 10/dev. This is assumed > to take a while. Right now we only integrate 9/hs to 9/dev once a week, > and at most we can crank that up to twice a week due to the rigorous > testing requirements. Once we get Mach 5 support for HotSpot testing > (running all the required VM tests) we can start integrating more often. Thanks Jesper. So it is going to be a while before we have a jdk10/hs that we can reliably push to via JPRT. We will also have to watch for issues introduced in jdk9/dev (which we would fix in jdk9/hs) getting taken into jdk10/dev and then jdk10/hs, as the fix will take a long time to reach jdk10/hs! David > HTH, > /Jesper > > Den 26/1/17 kl. 14:43, skrev Philip Race: >> So there is an expectation that 10-hs is seeded from 9-hs and so forth ? >> I guess not just for seeding, but on-going the sync will be from >> jdk9/jdk9 >> no matter what the destination forest. >> >> -phil.. >> >> >> >> On 1/26/17, 4:31 AM, Alan Bateman wrote: >>>> >>> The jdk10 forests seem to be seeded with jdk-9+153, I suspect David >>> is looking for changes are that backed up in jdk9/hs and haven't made >>> it into a JDK 9 promoted build yet. > From mark.reinhold at oracle.com Thu Jan 26 21:55:32 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 26 Jan 2017 13:55:32 -0800 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> <5889FD1D.7070004@oracle.com> Message-ID: <20170126135532.927730295@eggemoggin.niobe.net> 2017/1/26 8:12:20 -0800, jesper.wilhelmsson at oracle.com: > I'm not the decision maker here, but this is what was said in a meeting: > > The jdk10/jdk10 forest will sync with jdk9/dev. New changes in jdk9/dev is > pulled into 10 this way. The process is planned to be made automatic using Mach > 5 but initially Lana and I will be doing the integrations. > > jdk10/hs is a child of jdk10/dev. For changes to go from jdk9/hs to jdk10/hs > they will have to go through 9/dev and 10/dev. This is assumed to take a while. > Right now we only integrate 9/hs to 9/dev once a week, and at most we can crank > that up to twice a week due to the rigorous testing requirements. Once we get > Mach 5 support for HotSpot testing (running all the required VM tests) we can > start integrating more often. Right -- thanks for the summary! - Mark From bob.vandette at oracle.com Thu Jan 26 22:03:55 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 26 Jan 2017 17:03:55 -0500 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <20170126135532.927730295@eggemoggin.niobe.net> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> <5889FD1D.7070004@oracle.com> <20170126135532.927730295@eggemoggin.niobe.net> Message-ID: <49155A2F-7E6A-477F-8478-8869DEA659FB@oracle.com> I have a JDK 10 specific hotspot change that I?d like to get integrated into 10. The work is done but needs a review. During the review I?ll see what the consensus is on how destabilizing this change is. This will not get back ported to JDK 9. Where should this change be integrated to, jdk10/dev or jdk10/hs? How often will changes be pulled from jdk10/dev to jdk10/hs? Thanks, Bob. > On Jan 26, 2017, at 4:55 PM, mark.reinhold at oracle.com wrote: > > 2017/1/26 8:12:20 -0800, jesper.wilhelmsson at oracle.com: >> I'm not the decision maker here, but this is what was said in a meeting: >> >> The jdk10/jdk10 forest will sync with jdk9/dev. New changes in jdk9/dev is >> pulled into 10 this way. The process is planned to be made automatic using Mach >> 5 but initially Lana and I will be doing the integrations. >> >> jdk10/hs is a child of jdk10/dev. For changes to go from jdk9/hs to jdk10/hs >> they will have to go through 9/dev and 10/dev. This is assumed to take a while. >> Right now we only integrate 9/hs to 9/dev once a week, and at most we can crank >> that up to twice a week due to the rigorous testing requirements. Once we get >> Mach 5 support for HotSpot testing (running all the required VM tests) we can >> start integrating more often. > > Right -- thanks for the summary! > > - Mark From joe.darcy at oracle.com Thu Jan 26 22:30:27 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 Jan 2017 14:30:27 -0800 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <49155A2F-7E6A-477F-8478-8869DEA659FB@oracle.com> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> <0a29b6d3-98b9-e7de-4418-7efc34a7bca9@oracle.com> <5192ef74-5d7b-21bc-c4fb-28d2f0e21bfe@oracle.com> <5889FD1D.7070004@oracle.com> <20170126135532.927730295@eggemoggin.niobe.net> <49155A2F-7E6A-477F-8478-8869DEA659FB@oracle.com> Message-ID: Hello, On 1/26/2017 2:03 PM, Bob Vandette wrote: > I have a JDK 10 specific hotspot change that I?d like to get integrated into 10. > The work is done but needs a review. During the review I?ll see what the consensus > is on how destabilizing this change is. This will not get back ported to JDK 9. > > Where should this change be integrated to, jdk10/dev or jdk10/hs? HotSpot changes specific to JDK 10 should first go into jdk10/hs. At some regular interval, jdk10/hs will be integrated into jdk10/jdk10, similar to how jdk9/hs and jdk10/dev relate today. > > How often will changes be pulled from jdk10/dev to jdk10/hs? In the steady state, the syncs down from jdk10/jdk10 into jdk10/hs should be no less frequent than the syncs of jdk9/dev into jdk9/hs today. However, I think it would be beneficial for both the syncs down from jdk10/jdk10 into jdk10/hs and the integrations up from jdk10/hs into jdk10/jdk10 to occur more frequently than today. However, the testing situation needs to improve somewhat to allow that to happen reasonably. As jdk10 is starting up when some are still focused on 9, there may be a transient period where jdk10 activities are less frequent than corresponding activities in 9, but that period shouldn't be too prolonged. HTH, -Joe > > Thanks, > Bob. > > >> On Jan 26, 2017, at 4:55 PM, mark.reinhold at oracle.com wrote: >> >> 2017/1/26 8:12:20 -0800, jesper.wilhelmsson at oracle.com: >>> I'm not the decision maker here, but this is what was said in a meeting: >>> >>> The jdk10/jdk10 forest will sync with jdk9/dev. New changes in jdk9/dev is >>> pulled into 10 this way. The process is planned to be made automatic using Mach >>> 5 but initially Lana and I will be doing the integrations. >>> >>> jdk10/hs is a child of jdk10/dev. For changes to go from jdk9/hs to jdk10/hs >>> they will have to go through 9/dev and 10/dev. This is assumed to take a while. >>> Right now we only integrate 9/hs to 9/dev once a week, and at most we can crank >>> that up to twice a week due to the rigorous testing requirements. Once we get >>> Mach 5 support for HotSpot testing (running all the required VM tests) we can >>> start integrating more often. >> Right -- thanks for the summary! >> >> - Mark