From joe.darcy at oracle.com Sun Dec 1 21:04:08 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 01 Dec 2013 21:04:08 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <52935368.8050408@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> Message-ID: <529C14C8.8000105@oracle.com> Hi Dalibor, On 11/25/2013 5:40 AM, Dalibor Topic wrote: > On 11/23/13 5:34 PM, Joe Darcy wrote: >> Since more projects requiring cross-repository coordination are expected in the future, I'm proposing a number of changes to the forest structure and management policies in JDK 9 to reduce the propagation delays. > This seems very close to how 7u works already, so it's a huge improvement over 8, but it comes with some historical baggage: > >> By having team forests integrate directly into dev as well as having many libraries developers pushing directly to dev, the dev forest serves as an active collaboration area with greatly reduced propagation times across the whole system. With this model there is less cross-team isolation; teams and individuals are responsible for promptly fixing any breakage which is introduced. If problems are not quickly addressed, a problematic changeset may be anti-delta'ed. > One of the useful things we did for 7u was to try to drive down the number of team forests to just -dev. We didn't quite succeed, as you can see from the hotspot team having their own 7u integration forest, but overall it was a major step in driving the complexity of (un)necessary interactions down, and enabling fixes to propagate faster. > > I would suggest that you consider doing something similar for JDK 9, as the spider web [0] of JDK 8's forests currently contains about a dozen of forests, and from the way the proposal is written it seems that you may like to do that, but unfortunately the proposal is not very explicit about it. > > So, I'd like to suggest that jdk9/dev replaces the equivalent of jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. For the open components, that is essentially the proposal. Deploy and install are closed and have different testing requirements from other code so would likely remain separate. > If long term features require a throw-away integration forest, create one as you need it for as long as you need it, integrate and close that forest. > > I don't have an opinion on pruning hotspot forests (yet;), but you may want to consider where a fix containing changes both for hotspot and libraries would need to go to if you retain the current structure - gc? rt? hotspot-dev? hsx25? main? comp? At least in JDK 8, I believe most of libs + HotSpot interactions were in runtime, so a push to rt would be most appropriate in that case. In general, I would recommend a coordinated push go into the HotSpot integration forest with the closest interaction. > >> (Conceptually, in this model a separate master forest is not strictly needed since the known-good states could be indicated using a mechanism like Hg tags. However, while adjusting to the new model and to allow for fixes directly to master in exceptional circumstances, I'm proposing a physically separate master forest be retained. The distinct URL of master will also clearly indicate known-good states of the source code.) > One of the not very useful things we did for 7u was to keep a separate master forest. > > Considering the real benefits of a master forest [1], and the real drawbacks when it's being used with a rapidly changing tree underneath [2], I'd suggest you drop the master forest for JDK 9. Thanks for the feedback on that point of the proposal; I'm still uncomfortable with collapsing master and dev before we put the model into practice. > > One thing missing from the proposal is jdk9 repository layout within the forests. I think that this may be good opportunity to simplify the current historically grown structure, for example by folding the nashorn and langtools repositories together, as well as corba, jaxp, jaxws and jdk. Yes, that would be another level of reorganization to discuss. Cheers, -Joe From joe.darcy at oracle.com Sun Dec 1 21:14:58 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 01 Dec 2013 21:14:58 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <5295B2B9.9080003@oracle.com> References: <5290D912.7090002@oracle.com> <52936A88.2010306@oracle.com> <5294D69D.3070401@oracle.com> <5295B2B9.9080003@oracle.com> Message-ID: <529C1752.8040401@oracle.com> On 11/27/2013 12:52 AM, David Holmes wrote: > On 27/11/2013 3:13 AM, Joe Darcy wrote: >> On 11/25/2013 7:19 AM, Chris Hegarty wrote: >>> I am really happy to see this issue being discussed. I'm in favor of >>> fewer, simpler structured, forests, and this proposal seems to give >>> that. >>> >>> There is one potential issue I see. Having done several bulk >>> integrations into jdk8/tl over the past year, I found it nearly >>> impossible to get a stable/quite jdk8/tl. Ignoring the stability issue >>> for now ( being discussed in another thread ), if hotspot is to >>> integrate into -dev it will be nearly impossible to for the integrator >>> to actually build and test, the latest source, before pushing. As the >>> underlying repos in -dev are bound to be moving at a fast pace. >>> >>> It is worth noting that currently this is not an issue as master is >>> quite, apart from the scheduled/well known integration slots. >>> >>> Apart from the bulk integrations I did into jdk8/tl, I'm not sure that >>> anyone else downstream is doing anything similar. If so, then their >>> experiences here would be useful. >>> >>> This said, I'm still in favor of the current proposal, just maybe >>> needs more specifics around integrations. >> >> Just a quick comment for now, for this reasons and others, I think it >> would be helpful if we moved the JDK to a more continuous integration >> model. The sort of challenges we have in JDK integration are exactly the >> sort of situations CI can help. > > I often hear CI being touted as some kind of silver bullet but I am > yet to see how it actually helps. I would be interested to get some > details both on what "CI" means exactly and what problems it resolves > (and what problems it introduces). > We've found the "Continuous Delivery" book by Jez Humble and David Farley to be useful. Some relevant quotes from the first chapter or two of that text: > > If It Hurts, Do It More Frequently, and Bring the Pain Forward > "This is the most general principle on our list, and could perhaps > best be described as a heuristic. But it is perhaps the most useful > heuristic we know of in the context of delivering software, and it > informs everything we say." > > Integration is often a very painful process. > "If this is true of your project, integrate every time somebody checks > in, and do it from the start of the project. > If testing is a painful process that occurs just before release, don?t > do it at the end. Instead, do it continually from the beginning of the > project." HTH, -Joe From dmitry.samersoff at oracle.com Sun Dec 1 21:50:18 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 02 Dec 2013 09:50:18 +0400 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C14C8.8000105@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> Message-ID: <529C1F9A.9080201@oracle.com> Joe, Could we at least merge tl and hotspot-rt workspaces to a single one - tl-hotspot-rt? Pushing JDK fixes to hotspot-rt and than merge it into tl a week or two later could be a pain because hotspot-rt has limited set of JDK tests in nightly and lots of changes happens in tl within a week. -Dmitry On 2013-12-02 09:04, Joe Darcy wrote: > Hi Dalibor, > > On 11/25/2013 5:40 AM, Dalibor Topic wrote: >> On 11/23/13 5:34 PM, Joe Darcy wrote: >>> Since more projects requiring cross-repository coordination are >>> expected in the future, I'm proposing a number of changes to the >>> forest structure and management policies in JDK 9 to reduce the >>> propagation delays. >> This seems very close to how 7u works already, so it's a huge >> improvement over 8, but it comes with some historical baggage: >> >>> By having team forests integrate directly into dev as well as having >>> many libraries developers pushing directly to dev, the dev forest >>> serves as an active collaboration area with greatly reduced >>> propagation times across the whole system. With this model there is >>> less cross-team isolation; teams and individuals are responsible for >>> promptly fixing any breakage which is introduced. If problems are not >>> quickly addressed, a problematic changeset may be anti-delta'ed. >> One of the useful things we did for 7u was to try to drive down the >> number of team forests to just -dev. We didn't quite succeed, as you >> can see from the hotspot team having their own 7u integration forest, >> but overall it was a major step in driving the complexity of >> (un)necessary interactions down, and enabling fixes to propagate faster. >> >> I would suggest that you consider doing something similar for JDK 9, >> as the spider web [0] of JDK 8's forests currently contains about a >> dozen of forests, and from the way the proposal is written it seems >> that you may like to do that, but unfortunately the proposal is not >> very explicit about it. >> >> So, I'd like to suggest that jdk9/dev replaces the equivalent of >> jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, >> jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. > > For the open components, that is essentially the proposal. Deploy and > install are closed and have different testing requirements from other > code so would likely remain separate. > >> If long term features require a throw-away integration forest, >> create one as you need it for as long as you need it, integrate and >> close that forest. >> >> I don't have an opinion on pruning hotspot forests (yet;), but you may >> want to consider where a fix containing changes both for hotspot and >> libraries would need to go to if you retain the current structure - >> gc? rt? hotspot-dev? hsx25? main? comp? > > At least in JDK 8, I believe most of libs + HotSpot interactions were in > runtime, so a push to rt would be most appropriate in that case. In > general, I would recommend a coordinated push go into the HotSpot > integration forest with the closest interaction. > >> >>> (Conceptually, in this model a separate master forest is not strictly >>> needed since the known-good states could be indicated using a >>> mechanism like Hg tags. However, while adjusting to the new model and >>> to allow for fixes directly to master in exceptional circumstances, >>> I'm proposing a physically separate master forest be retained. The >>> distinct URL of master will also clearly indicate known-good states >>> of the source code.) >> One of the not very useful things we did for 7u was to keep a separate >> master forest. >> >> Considering the real benefits of a master forest [1], and the real >> drawbacks when it's being used with a rapidly changing tree underneath >> [2], I'd suggest you drop the master forest for JDK 9. > > Thanks for the feedback on that point of the proposal; I'm still > uncomfortable with collapsing master and dev before we put the model > into practice. > >> >> One thing missing from the proposal is jdk9 repository layout within >> the forests. I think that this may be good opportunity to simplify the >> current historically grown structure, for example by folding the >> nashorn and langtools repositories together, as well as corba, jaxp, >> jaxws and jdk. > > Yes, that would be another level of reorganization to discuss. > > Cheers, > > -Joe -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From dalibor.topic at oracle.com Mon Dec 2 02:04:48 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 02 Dec 2013 11:04:48 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C1752.8040401@oracle.com> References: <5290D912.7090002@oracle.com> <52936A88.2010306@oracle.com> <5294D69D.3070401@oracle.com> <5295B2B9.9080003@oracle.com> <529C1752.8040401@oracle.com> Message-ID: <529C5B40.20208@oracle.com> On 12/2/13 6:14 AM, Joe Darcy wrote: >> If It Hurts, Do It More Frequently, and Bring the Pain Forward >> "This is the most general principle on our list, and could perhaps best be described as a heuristic. But it is perhaps the most useful heuristic we know of in the context of delivering software, and it informs everything we say." Yeah, that was something I noticed while we were spinning up 7u - anything that can fail will at some point fail, and then the things you didn't think could fail will fail eventually as well. So it's better to go through a number of failures early, while you flush out the development processes, the code-to-build pipeline, the integrations, and all the other boundary conditions between soft issues and hard issues, etc. then to be hit with them when you don't really have much time for them later in a release's cycle. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Mon Dec 2 02:22:04 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 02 Dec 2013 11:22:04 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C14C8.8000105@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> Message-ID: <529C5F4C.9050708@oracle.com> On 12/2/13 6:04 AM, Joe Darcy wrote: >> So, I'd like to suggest that jdk9/dev replaces the equivalent of jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. > > For the open components, that is essentially the proposal. Deploy and install are closed and have different testing requirements from other code so would likely remain separate. Cool. Fwiw, I only mentioned deploy in there because there is a jdk8/deploy 'scratch' forest on hg.openjdk.java.net which presumably just complements a closed one to make integrations simpler. In practice, I don't think that it's very useful to have such setups where a closed forest has an OpenJDK counterpart and no actual development is done in OpenJDK - at best it leads to confusion, at worst it leads to spurious changes that have to be done because of the poor, established repository & forest layout, rather then because they make technical sense. > Thanks for the feedback on that point of the proposal; I'm still uncomfortable with collapsing master and dev before we put the model into practice. No problem - I'm glad to hear that you are not objecting to it on principle, and assuming the new model works out for 9, there could be other opportunities to try it out. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From staffan.larsen at oracle.com Mon Dec 2 05:19:09 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 2 Dec 2013 14:19:09 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C1F9A.9080201@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <529C1F9A.9080201@oracle.com> Message-ID: <1142DCF7-42B1-4307-B22A-74D32C257EBF@oracle.com> Dmitry, We could (and should) increase the set of JDK tests we run in hotspot-rt nightlies. /Staffan On 2 dec 2013, at 06:50, Dmitry Samersoff wrote: > Joe, > > Could we at least merge tl and hotspot-rt workspaces to a single one - > tl-hotspot-rt? > > Pushing JDK fixes to hotspot-rt and than merge it into tl a week or two > later could be a pain because hotspot-rt has limited set of JDK tests in > nightly and lots of changes happens in tl within a week. > > -Dmitry > > On 2013-12-02 09:04, Joe Darcy wrote: >> Hi Dalibor, >> >> On 11/25/2013 5:40 AM, Dalibor Topic wrote: >>> On 11/23/13 5:34 PM, Joe Darcy wrote: >>>> Since more projects requiring cross-repository coordination are >>>> expected in the future, I'm proposing a number of changes to the >>>> forest structure and management policies in JDK 9 to reduce the >>>> propagation delays. >>> This seems very close to how 7u works already, so it's a huge >>> improvement over 8, but it comes with some historical baggage: >>> >>>> By having team forests integrate directly into dev as well as having >>>> many libraries developers pushing directly to dev, the dev forest >>>> serves as an active collaboration area with greatly reduced >>>> propagation times across the whole system. With this model there is >>>> less cross-team isolation; teams and individuals are responsible for >>>> promptly fixing any breakage which is introduced. If problems are not >>>> quickly addressed, a problematic changeset may be anti-delta'ed. >>> One of the useful things we did for 7u was to try to drive down the >>> number of team forests to just -dev. We didn't quite succeed, as you >>> can see from the hotspot team having their own 7u integration forest, >>> but overall it was a major step in driving the complexity of >>> (un)necessary interactions down, and enabling fixes to propagate faster. >>> >>> I would suggest that you consider doing something similar for JDK 9, >>> as the spider web [0] of JDK 8's forests currently contains about a >>> dozen of forests, and from the way the proposal is written it seems >>> that you may like to do that, but unfortunately the proposal is not >>> very explicit about it. >>> >>> So, I'd like to suggest that jdk9/dev replaces the equivalent of >>> jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, >>> jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. >> >> For the open components, that is essentially the proposal. Deploy and >> install are closed and have different testing requirements from other >> code so would likely remain separate. >> >>> If long term features require a throw-away integration forest, >>> create one as you need it for as long as you need it, integrate and >>> close that forest. >>> >>> I don't have an opinion on pruning hotspot forests (yet;), but you may >>> want to consider where a fix containing changes both for hotspot and >>> libraries would need to go to if you retain the current structure - >>> gc? rt? hotspot-dev? hsx25? main? comp? >> >> At least in JDK 8, I believe most of libs + HotSpot interactions were in >> runtime, so a push to rt would be most appropriate in that case. In >> general, I would recommend a coordinated push go into the HotSpot >> integration forest with the closest interaction. >> >>> >>>> (Conceptually, in this model a separate master forest is not strictly >>>> needed since the known-good states could be indicated using a >>>> mechanism like Hg tags. However, while adjusting to the new model and >>>> to allow for fixes directly to master in exceptional circumstances, >>>> I'm proposing a physically separate master forest be retained. The >>>> distinct URL of master will also clearly indicate known-good states >>>> of the source code.) >>> One of the not very useful things we did for 7u was to keep a separate >>> master forest. >>> >>> Considering the real benefits of a master forest [1], and the real >>> drawbacks when it's being used with a rapidly changing tree underneath >>> [2], I'd suggest you drop the master forest for JDK 9. >> >> Thanks for the feedback on that point of the proposal; I'm still >> uncomfortable with collapsing master and dev before we put the model >> into practice. >> >>> >>> One thing missing from the proposal is jdk9 repository layout within >>> the forests. I think that this may be good opportunity to simplify the >>> current historically grown structure, for example by folding the >>> nashorn and langtools repositories together, as well as corba, jaxp, >>> jaxws and jdk. >> >> Yes, that would be another level of reorganization to discuss. >> >> Cheers, >> >> -Joe > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the source code. From dmitry.samersoff at oracle.com Mon Dec 2 06:59:04 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 02 Dec 2013 18:59:04 +0400 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <1142DCF7-42B1-4307-B22A-74D32C257EBF@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <529C1F9A.9080201@oracle.com> <1142DCF7-42B1-4307-B22A-74D32C257EBF@oracle.com> Message-ID: <529CA038.9030501@oracle.com> Staffan, tl is very busy forest. So if we have fixes A1 ... A5 in hotspot-rt and B1 ... B30 in tl, we have to repeat all JDK tests because we tested JDK fix with obsoleted codebase. Of course it's not always true, but it might be a problem. Also, for hotspot we have a method (jprt build) to confirm that merge is correct before actually push the changes to ws. For JDK we don't have such method yet so we should either keep tl locket for at least one nightly after merge or it's possible for incorrect merge to spread across developers. I think pushing hotspot changes to tl is much safer than push jdk changes to rt. But the best (IMHO) just have one workspace. -Dmitry On 2013-12-02 17:19, Staffan Larsen wrote: > Dmitry, > > We could (and should) increase the set of JDK tests we run in hotspot-rt nightlies. > > /Staffan > > On 2 dec 2013, at 06:50, Dmitry Samersoff wrote: > >> Joe, >> >> Could we at least merge tl and hotspot-rt workspaces to a single one - >> tl-hotspot-rt? >> >> Pushing JDK fixes to hotspot-rt and than merge it into tl a week or two >> later could be a pain because hotspot-rt has limited set of JDK tests in >> nightly and lots of changes happens in tl within a week. >> >> -Dmitry >> >> On 2013-12-02 09:04, Joe Darcy wrote: >>> Hi Dalibor, >>> >>> On 11/25/2013 5:40 AM, Dalibor Topic wrote: >>>> On 11/23/13 5:34 PM, Joe Darcy wrote: >>>>> Since more projects requiring cross-repository coordination are >>>>> expected in the future, I'm proposing a number of changes to the >>>>> forest structure and management policies in JDK 9 to reduce the >>>>> propagation delays. >>>> This seems very close to how 7u works already, so it's a huge >>>> improvement over 8, but it comes with some historical baggage: >>>> >>>>> By having team forests integrate directly into dev as well as having >>>>> many libraries developers pushing directly to dev, the dev forest >>>>> serves as an active collaboration area with greatly reduced >>>>> propagation times across the whole system. With this model there is >>>>> less cross-team isolation; teams and individuals are responsible for >>>>> promptly fixing any breakage which is introduced. If problems are not >>>>> quickly addressed, a problematic changeset may be anti-delta'ed. >>>> One of the useful things we did for 7u was to try to drive down the >>>> number of team forests to just -dev. We didn't quite succeed, as you >>>> can see from the hotspot team having their own 7u integration forest, >>>> but overall it was a major step in driving the complexity of >>>> (un)necessary interactions down, and enabling fixes to propagate faster. >>>> >>>> I would suggest that you consider doing something similar for JDK 9, >>>> as the spider web [0] of JDK 8's forests currently contains about a >>>> dozen of forests, and from the way the proposal is written it seems >>>> that you may like to do that, but unfortunately the proposal is not >>>> very explicit about it. >>>> >>>> So, I'd like to suggest that jdk9/dev replaces the equivalent of >>>> jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, >>>> jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. >>> >>> For the open components, that is essentially the proposal. Deploy and >>> install are closed and have different testing requirements from other >>> code so would likely remain separate. >>> >>>> If long term features require a throw-away integration forest, >>>> create one as you need it for as long as you need it, integrate and >>>> close that forest. >>>> >>>> I don't have an opinion on pruning hotspot forests (yet;), but you may >>>> want to consider where a fix containing changes both for hotspot and >>>> libraries would need to go to if you retain the current structure - >>>> gc? rt? hotspot-dev? hsx25? main? comp? >>> >>> At least in JDK 8, I believe most of libs + HotSpot interactions were in >>> runtime, so a push to rt would be most appropriate in that case. In >>> general, I would recommend a coordinated push go into the HotSpot >>> integration forest with the closest interaction. >>> >>>> >>>>> (Conceptually, in this model a separate master forest is not strictly >>>>> needed since the known-good states could be indicated using a >>>>> mechanism like Hg tags. However, while adjusting to the new model and >>>>> to allow for fixes directly to master in exceptional circumstances, >>>>> I'm proposing a physically separate master forest be retained. The >>>>> distinct URL of master will also clearly indicate known-good states >>>>> of the source code.) >>>> One of the not very useful things we did for 7u was to keep a separate >>>> master forest. >>>> >>>> Considering the real benefits of a master forest [1], and the real >>>> drawbacks when it's being used with a rapidly changing tree underneath >>>> [2], I'd suggest you drop the master forest for JDK 9. >>> >>> Thanks for the feedback on that point of the proposal; I'm still >>> uncomfortable with collapsing master and dev before we put the model >>> into practice. >>> >>>> >>>> One thing missing from the proposal is jdk9 repository layout within >>>> the forests. I think that this may be good opportunity to simplify the >>>> current historically grown structure, for example by folding the >>>> nashorn and langtools repositories together, as well as corba, jaxp, >>>> jaxws and jdk. >>> >>> Yes, that would be another level of reorganization to discuss. >>> >>> Cheers, >>> >>> -Joe >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the source code. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From joe.darcy at oracle.com Mon Dec 2 09:19:00 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 02 Dec 2013 09:19:00 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C1F9A.9080201@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <529C1F9A.9080201@oracle.com> Message-ID: <529CC104.3000702@oracle.com> Hello Dmitry, In a future world, with better testing and better test stability, it would be reasonable to consider combining tl/dev and the HotSpot forests. However, that would not be an appropriate combination today. It would be possible (and encouraged!) for HotSpot main to pull down changes from dev on a regular basis, closer to daily rather than weekly. Cheers, -Joe On 12/01/2013 09:50 PM, Dmitry Samersoff wrote: > Joe, > > Could we at least merge tl and hotspot-rt workspaces to a single one - > tl-hotspot-rt? > > Pushing JDK fixes to hotspot-rt and than merge it into tl a week or two > later could be a pain because hotspot-rt has limited set of JDK tests in > nightly and lots of changes happens in tl within a week. > > -Dmitry > > On 2013-12-02 09:04, Joe Darcy wrote: >> Hi Dalibor, >> >> On 11/25/2013 5:40 AM, Dalibor Topic wrote: >>> On 11/23/13 5:34 PM, Joe Darcy wrote: >>>> Since more projects requiring cross-repository coordination are >>>> expected in the future, I'm proposing a number of changes to the >>>> forest structure and management policies in JDK 9 to reduce the >>>> propagation delays. >>> This seems very close to how 7u works already, so it's a huge >>> improvement over 8, but it comes with some historical baggage: >>> >>>> By having team forests integrate directly into dev as well as having >>>> many libraries developers pushing directly to dev, the dev forest >>>> serves as an active collaboration area with greatly reduced >>>> propagation times across the whole system. With this model there is >>>> less cross-team isolation; teams and individuals are responsible for >>>> promptly fixing any breakage which is introduced. If problems are not >>>> quickly addressed, a problematic changeset may be anti-delta'ed. >>> One of the useful things we did for 7u was to try to drive down the >>> number of team forests to just -dev. We didn't quite succeed, as you >>> can see from the hotspot team having their own 7u integration forest, >>> but overall it was a major step in driving the complexity of >>> (un)necessary interactions down, and enabling fixes to propagate faster. >>> >>> I would suggest that you consider doing something similar for JDK 9, >>> as the spider web [0] of JDK 8's forests currently contains about a >>> dozen of forests, and from the way the proposal is written it seems >>> that you may like to do that, but unfortunately the proposal is not >>> very explicit about it. >>> >>> So, I'd like to suggest that jdk9/dev replaces the equivalent of >>> jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, >>> jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. >> For the open components, that is essentially the proposal. Deploy and >> install are closed and have different testing requirements from other >> code so would likely remain separate. >> >>> If long term features require a throw-away integration forest, >>> create one as you need it for as long as you need it, integrate and >>> close that forest. >>> >>> I don't have an opinion on pruning hotspot forests (yet;), but you may >>> want to consider where a fix containing changes both for hotspot and >>> libraries would need to go to if you retain the current structure - >>> gc? rt? hotspot-dev? hsx25? main? comp? >> At least in JDK 8, I believe most of libs + HotSpot interactions were in >> runtime, so a push to rt would be most appropriate in that case. In >> general, I would recommend a coordinated push go into the HotSpot >> integration forest with the closest interaction. >> >>>> (Conceptually, in this model a separate master forest is not strictly >>>> needed since the known-good states could be indicated using a >>>> mechanism like Hg tags. However, while adjusting to the new model and >>>> to allow for fixes directly to master in exceptional circumstances, >>>> I'm proposing a physically separate master forest be retained. The >>>> distinct URL of master will also clearly indicate known-good states >>>> of the source code.) >>> One of the not very useful things we did for 7u was to keep a separate >>> master forest. >>> >>> Considering the real benefits of a master forest [1], and the real >>> drawbacks when it's being used with a rapidly changing tree underneath >>> [2], I'd suggest you drop the master forest for JDK 9. >> Thanks for the feedback on that point of the proposal; I'm still >> uncomfortable with collapsing master and dev before we put the model >> into practice. >> >>> One thing missing from the proposal is jdk9 repository layout within >>> the forests. I think that this may be good opportunity to simplify the >>> current historically grown structure, for example by folding the >>> nashorn and langtools repositories together, as well as corba, jaxp, >>> jaxws and jdk. >> Yes, that would be another level of reorganization to discuss. >> >> Cheers, >> >> -Joe > From vladimir.kozlov at oracle.com Mon Dec 2 09:55:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Dec 2013 09:55:49 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529CC104.3000702@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <529C1F9A.9080201@oracle.com> <529CC104.3000702@oracle.com> Message-ID: <529CC9A5.3010508@oracle.com> On 12/2/13 9:19 AM, Joe Darcy wrote: > Hello Dmitry, > > In a future world, with better testing and better test stability, it would be reasonable to consider combining tl/dev > and the HotSpot forests. However, that would not be an appropriate combination today. > > It would be possible (and encouraged!) for HotSpot main to pull down changes from dev on a regular basis, closer to > daily rather than weekly. It will only help for synchronized pushes into Hotspot and libs. Which is not such frequent (not daily). The main problem is Nightly testing of Hotspot. Currently we use jdk bundles prepared by JPRT when we push changes into Hotspot. JPRT uses promoted JDK and that is the problem. If we want to use latest dev changes for Hotspot testing we need to have daily builds from dev changes which JPRT can use. Yes, ideally it would be nice to build jdk for each Hotspot push and bundle it but JPRT does not have enough throughput for that now. Regards, Vladimir > > Cheers, > > -Joe > > On 12/01/2013 09:50 PM, Dmitry Samersoff wrote: >> Joe, >> >> Could we at least merge tl and hotspot-rt workspaces to a single one - >> tl-hotspot-rt? >> >> Pushing JDK fixes to hotspot-rt and than merge it into tl a week or two >> later could be a pain because hotspot-rt has limited set of JDK tests in >> nightly and lots of changes happens in tl within a week. >> >> -Dmitry >> >> On 2013-12-02 09:04, Joe Darcy wrote: >>> Hi Dalibor, >>> >>> On 11/25/2013 5:40 AM, Dalibor Topic wrote: >>>> On 11/23/13 5:34 PM, Joe Darcy wrote: >>>>> Since more projects requiring cross-repository coordination are >>>>> expected in the future, I'm proposing a number of changes to the >>>>> forest structure and management policies in JDK 9 to reduce the >>>>> propagation delays. >>>> This seems very close to how 7u works already, so it's a huge >>>> improvement over 8, but it comes with some historical baggage: >>>>> By having team forests integrate directly into dev as well as having >>>>> many libraries developers pushing directly to dev, the dev forest >>>>> serves as an active collaboration area with greatly reduced >>>>> propagation times across the whole system. With this model there is >>>>> less cross-team isolation; teams and individuals are responsible for >>>>> promptly fixing any breakage which is introduced. If problems are not >>>>> quickly addressed, a problematic changeset may be anti-delta'ed. >>>> One of the useful things we did for 7u was to try to drive down the >>>> number of team forests to just -dev. We didn't quite succeed, as you >>>> can see from the hotspot team having their own 7u integration forest, >>>> but overall it was a major step in driving the complexity of >>>> (un)necessary interactions down, and enabling fixes to propagate faster. >>>> >>>> I would suggest that you consider doing something similar for JDK 9, >>>> as the spider web [0] of JDK 8's forests currently contains about a >>>> dozen of forests, and from the way the proposal is written it seems >>>> that you may like to do that, but unfortunately the proposal is not >>>> very explicit about it. >>>> >>>> So, I'd like to suggest that jdk9/dev replaces the equivalent of >>>> jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, >>>> jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. >>> For the open components, that is essentially the proposal. Deploy and >>> install are closed and have different testing requirements from other >>> code so would likely remain separate. >>> >>>> If long term features require a throw-away integration forest, >>>> create one as you need it for as long as you need it, integrate and >>>> close that forest. >>>> >>>> I don't have an opinion on pruning hotspot forests (yet;), but you may >>>> want to consider where a fix containing changes both for hotspot and >>>> libraries would need to go to if you retain the current structure - >>>> gc? rt? hotspot-dev? hsx25? main? comp? >>> At least in JDK 8, I believe most of libs + HotSpot interactions were in >>> runtime, so a push to rt would be most appropriate in that case. In >>> general, I would recommend a coordinated push go into the HotSpot >>> integration forest with the closest interaction. >>> >>>>> (Conceptually, in this model a separate master forest is not strictly >>>>> needed since the known-good states could be indicated using a >>>>> mechanism like Hg tags. However, while adjusting to the new model and >>>>> to allow for fixes directly to master in exceptional circumstances, >>>>> I'm proposing a physically separate master forest be retained. The >>>>> distinct URL of master will also clearly indicate known-good states >>>>> of the source code.) >>>> One of the not very useful things we did for 7u was to keep a separate >>>> master forest. >>>> >>>> Considering the real benefits of a master forest [1], and the real >>>> drawbacks when it's being used with a rapidly changing tree underneath >>>> [2], I'd suggest you drop the master forest for JDK 9. >>> Thanks for the feedback on that point of the proposal; I'm still >>> uncomfortable with collapsing master and dev before we put the model >>> into practice. >>> >>>> One thing missing from the proposal is jdk9 repository layout within >>>> the forests. I think that this may be good opportunity to simplify the >>>> current historically grown structure, for example by folding the >>>> nashorn and langtools repositories together, as well as corba, jaxp, >>>> jaxws and jdk. >>> Yes, that would be another level of reorganization to discuss. >>> >>> Cheers, >>> >>> -Joe >> > From jonathan.gibbons at oracle.com Mon Dec 2 11:35:37 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 02 Dec 2013 11:35:37 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C1752.8040401@oracle.com> References: <5290D912.7090002@oracle.com> <52936A88.2010306@oracle.com> <5294D69D.3070401@oracle.com> <5295B2B9.9080003@oracle.com> <529C1752.8040401@oracle.com> Message-ID: <529CE109.2090202@oracle.com> On 12/01/2013 09:14 PM, Joe Darcy wrote: > We've found the "Continuous Delivery" book by Jez Humble and David > Farley to be useful. > > Some relevant quotes from the first chapter or two of that text: > >> >> If It Hurts, Do It More Frequently, and Bring the Pain Forward >> "This is the most general principle on our list, and could perhaps >> best be described as a heuristic. But it is perhaps the most useful >> heuristic we know of in the context of delivering software, and it >> informs everything we say." >> >> Integration is often a very painful process. >> "If this is true of your project, integrate every time somebody >> checks in, and do it from the start of the project. >> If testing is a painful process that occurs just before release, >> don?t do it at the end. Instead, do it continually from the beginning >> of the project." I like the term "Continuous Delivery" as compared to "Continuous Integration" since Integration is such as loaded term in our current infrastructure. I also like +100 the comment about testing ... -- Jon From mark.reinhold at oracle.com Mon Dec 2 11:38:45 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 02 Dec 2013 11:38:45 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <5292A4AC.7090700@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> Message-ID: <20131202113845.390471@eggemoggin.niobe.net> 2013/11/24 9:15 -0800, joe.darcy at oracle.com: > On 11/24/2013 4:17 AM, Alan Bateman wrote: >> I haven't see any comments yet from folks that currently push to >> jdk8/awt and jdk8/2d but one thing that is an unknown (to me at least) >> is whether there is any non-automatic testing that needs to happen >> before the changes go into master. If there is then I just wonder what >> this means for a weekly or bi-weekly integration from dev to master. >> Maybe it's no different to today, at least in the short term. > > A detail I omitted from the earlier description, the client libraries > (awt, 2d, swing, etc.) and core libraries are integrated into master > simultaneous even though they come from separate forests now. (The > integrator creates a side forest with the combined set of client and > core fixes. This goes through build + test before getting pushed to master.) > > One side-effect of the proposal is that the client libs and core libs > changes will get mingled a bit sooner than currently. That's no doubt a good thing, but are we confident that we'll be able to do such an integration every week, including any necessary manual testing of client code? If not then it seems we need a separate client forest that feeds into the dev forest after appropriate testing, just like the HotSpot forests. - Mark From mark.reinhold at oracle.com Mon Dec 2 11:50:35 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 02 Dec 2013 11:50:35 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C14C8.8000105@oracle.com> References: <5290D912.7090002@oracle.com>, <52935368.8050408@oracle.com>, <529C14C8.8000105@oracle.com> Message-ID: <20131202115035.797919@eggemoggin.niobe.net> 2013/12/1 13:04 -0800, joe.darcy at oracle.com: > On 11/25/2013 5:40 AM, Dalibor Topic wrote: >>> (Conceptually, in this model a separate master forest is not >>> strictly needed since the known-good states could be indicated using >>> a mechanism like Hg tags. However, while adjusting to the new model >>> and to allow for fixes directly to master in exceptional >>> circumstances, I'm proposing a physically separate master forest be >>> retained. The distinct URL of master will also clearly indicate >>> known-good states of the source code.) >> >> One of the not very useful things we did for 7u was to keep a >> separate master forest. >> >> Considering the real benefits of a master forest [1], and the real >> drawbacks when it's being used with a rapidly changing tree >> underneath [2], I'd suggest you drop the master forest for JDK 9. > > Thanks for the feedback on that point of the proposal; I'm still > uncomfortable with collapsing master and dev before we put the model > into practice. Can you say more about your discomfort? Eliminating the master/dev distinction is another good simplification, I think, and if we're going to shake things up anyway then now is a good time to do it. Is your concern mainly that consumers of the master forest will have to change their habits, and always look for the current build tag? One way to make that easier would be to define another tag, say jdk9-current, that also tags the latest jdk9-bXXX changesets. - Mark From david.dehaven at oracle.com Mon Dec 2 14:25:58 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 2 Dec 2013 14:25:58 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C5F4C.9050708@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <529C5F4C.9050708@oracle.com> Message-ID: <9EF695CB-AD61-4F69-AE3D-49C0CD4C3403@oracle.com> >>> So, I'd like to suggest that jdk9/dev replaces the equivalent of jdk9/tl, jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, jdk9/l10n, jdk9/swing, nashorn/jdk9 in one go. >> >> For the open components, that is essentially the proposal. Deploy and install are closed and have different testing requirements from other code so would likely remain separate. > > Cool. Fwiw, I only mentioned deploy in there because there is a jdk8/deploy 'scratch' forest on hg.openjdk.java.net which presumably just complements a closed one to make integrations simpler. > > In practice, I don't think that it's very useful to have such setups where a closed forest has an OpenJDK counterpart and no actual development is done in OpenJDK - at best it leads to confusion, at worst it leads to spurious changes that have to be done because of the poor, established repository & forest layout, rather then because they make technical sense. (speaking as a member of the deploy team...) A majority of this particular discussion needs to be done offline, but I'm not entirely convinced that we need to continue to have our own OpenJDK forest. The several times I've needed changes outside of deploy I've had to go through a different workspace (such as awt or tl) which means the corresponding deploy changes have to wait at least one integration cycle for those changes to trickle over to our workspace (then I have to pester someone to synchronize our OpenJDK forest with master), lest our builds be broken by half-implemented changes. On the flip side, we've had issues where changes or improvements were made in jdk or hotspot and we don't see them for weeks or months because they're not synced up in a timely fashion. Any way to improve that would get my vote. -DrD- From daniel.smith at oracle.com Mon Dec 2 15:34:59 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 2 Dec 2013 16:34:59 -0700 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529C14C8.8000105@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> Message-ID: <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> On Dec 1, 2013, at 10:04 PM, Joe Darcy wrote: >> One thing missing from the proposal is jdk9 repository layout within the forests. I think that this may be good opportunity to simplify the current historically grown structure, for example by folding the nashorn and langtools repositories together, as well as corba, jaxp, jaxws and jdk. > > Yes, that would be another level of reorganization to discuss. What I'd like to see here, and I think what's probably the general preference, is a single repository. I've got nothing against having as many subdirectories of jdk9 as necessary, but they don't need to be separate repositories. I'm not aware of any advantages to the forest approach, and it has some pretty annoying downsides (e.g., the project is less accessible to new participants; commits to separate subdirectories aren't serialized; work across multiple subdirectories is tedious). (I do recognize that: i) this is orthogonal to the changes originally proposed in this thread, and ii) there may be technical challenges that make this a nontrivial project.) ?Dan From lana.steuck at oracle.com Mon Dec 2 16:52:57 2013 From: lana.steuck at oracle.com (Lana Steuck) Date: Mon, 02 Dec 2013 16:52:57 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <20131202113845.390471@eggemoggin.niobe.net> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> Message-ID: <529D2B69.3080903@oracle.com> On 12/02/2013 11:38 AM, mark.reinhold at oracle.com wrote: > That's no doubt a good thing, but are we confident that we'll be able > to do such an integration every week, including any necessary manual > testing of client code? If not then it seems we need a separate client > forest that feeds into the dev forest after appropriate testing, just > like the HotSpot forests. > - Mark It seems that it would depend on SQE resources. If SQE could perform manual client testing of the pre-integration build weekly, then we could do weekly integrations of jdk9-dev. - Lana From joe.darcy at oracle.com Tue Dec 3 00:14:56 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 03 Dec 2013 00:14:56 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529D2B69.3080903@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> Message-ID: <529D9300.605@oracle.com> On 12/02/2013 04:52 PM, Lana Steuck wrote: > > On 12/02/2013 11:38 AM, mark.reinhold at oracle.com wrote: >> That's no doubt a good thing, but are we confident that we'll be able >> to do such an integration every week, including any necessary manual >> testing of client code? If not then it seems we need a separate >> client forest that feeds into the dev forest after appropriate >> testing, just like the HotSpot forests. - Mark > > It seems that it would depend on SQE resources. If SQE could perform > manual client testing of the pre-integration build weekly, then we > could do weekly integrations of jdk9-dev. > > - Lana > A few more thoughts on client library code. First, on a technological basis, client libraries are library code like the core libraries, living in the same repository and being built by the same makefile rules. In terms of volume of changes, looking at the number of bug fixes per component in JDK 8, the client libs component has fewer than half the fixes of either core-libs or hotspot: client-libs fixes in JDK 8: 840 core-libs fixes in JDK 8: 1983 hotspot fixes in JDK 8: 1778 To me, both of these factors argue in favor of combining core libs and client libs fixes in a single forest. Over time, throughout the JDK we should work to reduce the reliance on manual testing. My strong preference is to start JDK 9 *without* a forest dedicated to client libs changes and only add such a forest if that arrangement proves unworkable in practice. Fewer forests means testing efforts can be more focused. -Joe From joe.darcy at oracle.com Tue Dec 3 00:37:11 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 03 Dec 2013 00:37:11 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <20131202115035.797919@eggemoggin.niobe.net> References: <5290D912.7090002@oracle.com>, <52935368.8050408@oracle.com>, <529C14C8.8000105@oracle.com> <20131202115035.797919@eggemoggin.niobe.net> Message-ID: <529D9837.4050802@oracle.com> On 12/02/2013 11:50 AM, mark.reinhold at oracle.com wrote: > 2013/12/1 13:04 -0800, joe.darcy at oracle.com: >> On 11/25/2013 5:40 AM, Dalibor Topic wrote: >>>> (Conceptually, in this model a separate master forest is not >>>> strictly needed since the known-good states could be indicated using >>>> a mechanism like Hg tags. However, while adjusting to the new model >>>> and to allow for fixes directly to master in exceptional >>>> circumstances, I'm proposing a physically separate master forest be >>>> retained. The distinct URL of master will also clearly indicate >>>> known-good states of the source code.) >>> One of the not very useful things we did for 7u was to keep a >>> separate master forest. >>> >>> Considering the real benefits of a master forest [1], and the real >>> drawbacks when it's being used with a rapidly changing tree >>> underneath [2], I'd suggest you drop the master forest for JDK 9. >> Thanks for the feedback on that point of the proposal; I'm still >> uncomfortable with collapsing master and dev before we put the model >> into practice. > Can you say more about your discomfort? Eliminating the master/dev > distinction is another good simplification, I think, and if we're > going to shake things up anyway then now is a good time to do it. > > Is your concern mainly that consumers of the master forest will have > to change their habits, and always look for the current build tag? > > One way to make that easier would be to define another tag, say > jdk9-current, that also tags the latest jdk9-bXXX changesets. > I would expect some hiccups transitioning to the new model; dev *should* be stable, but a problem may be found later than desired, etc. Having a separate master forest, and the potential to make out-of-band integrations to it, allows an easy remedy to such a situation by doing what we do know. -Joe From artem.ananiev at oracle.com Tue Dec 3 02:16:29 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 03 Dec 2013 14:16:29 +0400 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529D9300.605@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529D9300.605@oracle.com> Message-ID: <529DAF7D.9020603@oracle.com> On 12/3/2013 12:14 PM, Joe Darcy wrote: > On 12/02/2013 04:52 PM, Lana Steuck wrote: >> >> On 12/02/2013 11:38 AM, mark.reinhold at oracle.com wrote: >>> That's no doubt a good thing, but are we confident that we'll be able >>> to do such an integration every week, including any necessary manual >>> testing of client code? If not then it seems we need a separate >>> client forest that feeds into the dev forest after appropriate >>> testing, just like the HotSpot forests. - Mark >> >> It seems that it would depend on SQE resources. If SQE could perform >> manual client testing of the pre-integration build weekly, then we >> could do weekly integrations of jdk9-dev. >> >> - Lana > > A few more thoughts on client library code. > > First, on a technological basis, client libraries are library code like > the core libraries, living in the same repository and being built by the > same makefile rules. > > In terms of volume of changes, looking at the number of bug fixes per > component in JDK 8, the client libs component has fewer than half the > fixes of either core-libs or hotspot: > > client-libs fixes in JDK 8: 840 > core-libs fixes in JDK 8: 1983 > hotspot fixes in JDK 8: 1778 > > To me, both of these factors argue in favor of combining core libs and > client libs fixes in a single forest. (Speaking as a client libs engineer) I agree. From the technical perspective, I don't see any problems with having a single forest for client and core libs teams. Client/core changesets usually don't intersect, merge conflicts are rare and easy to resolve. Less forests make the development and integration processes more transparent, so if we can afford it (in terms of SQE resources, first of all), let's do it. Thanks, Artem > Over time, throughout the JDK we should work to reduce the reliance on > manual testing. > > My strong preference is to start JDK 9 *without* a forest dedicated to > client libs changes and only add such a forest if that arrangement > proves unworkable in practice. Fewer forests means testing efforts can > be more focused. > > -Joe From Alan.Bateman at oracle.com Tue Dec 3 02:56:32 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Dec 2013 10:56:32 +0000 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529DAF7D.9020603@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529D9300.605@oracle.com> <529DAF7D.9020603@oracle.com> Message-ID: <529DB8E0.1010201@oracle.com> On 03/12/2013 10:16, Artem Ananiev wrote: > : > > (Speaking as a client libs engineer) > > I agree. > > From the technical perspective, I don't see any problems with having a > single forest for client and core libs teams. Client/core changesets > usually don't intersect, merge conflicts are rare and easy to resolve. > Less forests make the development and integration processes more > transparent, so if we can afford it (in terms of SQE resources, first > of all), let's do it. Do you have an insight into what manual testing is currently required before going into master? I'm curious if this testing is strictly required. Also I'm wondering if there has been any attempt to automate this (from a distance I see the AWT Robot class and naively assume that the automated UI testing nut was cracked a long time ago). -Alan. From artem.ananiev at oracle.com Tue Dec 3 04:38:30 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 03 Dec 2013 16:38:30 +0400 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529DB8E0.1010201@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529D9300.605@oracle.com> <529DAF7D.9020603@oracle.com> <529DB8E0.1010201@oracle.com> Message-ID: <529DD0C6.4050907@oracle.com> Hi, Alan, On 12/3/2013 2:56 PM, Alan Bateman wrote: > On 03/12/2013 10:16, Artem Ananiev wrote: >> : >> >> (Speaking as a client libs engineer) >> >> I agree. >> >> From the technical perspective, I don't see any problems with having a >> single forest for client and core libs teams. Client/core changesets >> usually don't intersect, merge conflicts are rare and easy to resolve. >> Less forests make the development and integration processes more >> transparent, so if we can afford it (in terms of SQE resources, first >> of all), let's do it. > Do you have an insight into what manual testing is currently required > before going into master? I'm curious if this testing is strictly > required. Also I'm wondering if there has been any attempt to automate > this (from a distance I see the AWT Robot class and naively assume that > the automated UI testing nut was cracked a long time ago). Currently, pre-integration testing is just running automated tests + verification of certain fixes. No manual testing. Manual tests are sometimes run against promoted builds, but SQE team already does weekly testing, so if client libs are integrated weekly instead of bi-weekly, nothing will change for them. AWT Robot is a great tool, but it has its limitations. Most of the troubles are caused by window managers, which are not under Robot control. Thanks, Artem > -Alan. From yuri.nesterenko at oracle.com Tue Dec 3 04:47:07 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 03 Dec 2013 16:47:07 +0400 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529D2B69.3080903@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> Message-ID: <529DD2CB.7080101@oracle.com> On 12/03/2013 04:52 AM, Lana Steuck wrote: > > On 12/02/2013 11:38 AM, mark.reinhold at oracle.com wrote: >> That's no doubt a good thing, but are we confident that we'll be able >> to do such an integration every week, including any necessary manual >> testing of client code? If not then it seems we need a separate client >> forest that feeds into the dev forest after appropriate testing, just >> like the HotSpot forests. - Mark > > It seems that it would depend on SQE resources. If SQE could perform > manual client testing of the pre-integration build weekly, then we could > do weekly integrations of jdk9-dev. > > - Lana > In fact, I think it may be even easier for SQE, here's a paradox. We hope to have nightly builds established, and thus be prepared for PIT very well; weekly routine is easier to plan in advance (and SQE is all about planning); finally, we don't really do full-profile manual testing for PIT. It's all automated + some sanity checks + cursory verification of actual fixes. This last task will be smaller if do it weekly. -yan From joe.darcy at oracle.com Tue Dec 3 10:47:32 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 03 Dec 2013 10:47:32 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> Message-ID: <529E2744.7070105@oracle.com> On 12/02/2013 03:34 PM, Dan Smith wrote: > On Dec 1, 2013, at 10:04 PM, Joe Darcy wrote: > >>> One thing missing from the proposal is jdk9 repository layout within the forests. I think that this may be good opportunity to simplify the current historically grown structure, for example by folding the nashorn and langtools repositories together, as well as corba, jaxp, jaxws and jdk. >> Yes, that would be another level of reorganization to discuss. > What I'd like to see here, and I think what's probably the general preference, is a single repository. I've got nothing against having as many subdirectories of jdk9 as necessary, but they don't need to be separate repositories. I'm not aware of any advantages to the forest approach, and it has some pretty annoying downsides (e.g., the project is less accessible to new participants; commits to separate subdirectories aren't serialized; work across multiple subdirectories is tedious). > > (I do recognize that: i) this is orthogonal to the changes originally proposed in this thread, and ii) there may be technical challenges that make this a nontrivial project.) > > ?Dan Just a quick note of historical perspective on this point, which was also raised previously by Andrew. In some ways, the JDK repositories are a downstream consumer of upstream versions of jaxp, javaws, and corba. There have been various code management issues in those areas over the years, some of them predating OpenJDK, such as a sync with upstream losing local changes in the JDK repo, etc. (Or from the perspective of the other project, JDK changes not being fed upstream.) The source bundle mechanism for jaxp and jax-ws from several years ago, now abandoned, was an effort to address some of these issues. Since that time, the primary distribution of jaxp has become the JDK version and there is improved coordination with jax-ws. The corba headwaters dried up many years ago. (There are several long-diverged versions of corba, one in the JDK another in EE; there has been some consideration of merging these versions, but the effort would be nontrivial.) The separate repositories for corba, jaxp, and jax-ws were put in place to reflect these differences in code origin and handling; however, I agree it is worthwhile to contemplate a repository consolidation, at least for all the libraries-related repos (jdk, corba, jaxp, jaxws). -Joe From Alan.Bateman at oracle.com Wed Dec 4 01:32:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Dec 2013 09:32:14 +0000 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529E2744.7070105@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> Message-ID: <529EF69E.8020902@oracle.com> On 03/12/2013 18:47, Joe Darcy wrote: > : > > The separate repositories for corba, jaxp, and jax-ws were put in > place to reflect these differences in code origin and handling; > however, I agree it is worthwhile to contemplate a repository > consolidation, at least for all the libraries-related repos (jdk, > corba, jaxp, jaxws). I agree that jaxp and corba should be looked at. That would also help with a number of awkward circular dependencies and build issues (the code in these two repositories really needs to be in the same big compilation unit as the code in the jdk repository, at least until we/if get to the point where the JDK is compiled as modules). Furthermore, the timing is probably right for JAXP as it has proposed to discontinue its standalone form and this opens the door to taking advantage of new Java Language features and APIs. I'm less sure about the jaxws repository as this is the transformation of code from a number of upstream projects. Having it in its own repository makes it a bit more obvious that we shouldn't be changing anything in that code (as it will be trashed by updates from upstream). Also it does not need to be compiled with the code in the jdk repository and actually doesn't need to be packaged in rt.jar either (but that is a separate topic). If nothing else, then I think that the code in the jaxws repository should be compiled after the jdk repository to avoid some of the boot cycle build issues that periodically arises with big updates from upstream. -Alan. From Paul.Sandoz at oracle.com Wed Dec 4 01:38:08 2013 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Dec 2013 10:38:08 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529CE109.2090202@oracle.com> References: <5290D912.7090002@oracle.com> <52936A88.2010306@oracle.com> <5294D69D.3070401@oracle.com> <5295B2B9.9080003@oracle.com> <529C1752.8040401@oracle.com> <529CE109.2090202@oracle.com> Message-ID: <6BED40BF-6259-4AE3-80EC-E26D088D27C1@oracle.com> On Dec 2, 2013, at 8:35 PM, Jonathan Gibbons wrote: > On 12/01/2013 09:14 PM, Joe Darcy wrote: >> We've found the "Continuous Delivery" book by Jez Humble and David Farley to be useful. >> >> Some relevant quotes from the first chapter or two of that text: >> >>> >>> If It Hurts, Do It More Frequently, and Bring the Pain Forward >>> "This is the most general principle on our list, and could perhaps best be described as a heuristic. But it is perhaps the most useful heuristic we know of in the context of delivering software, and it informs everything we say." >>> >>> Integration is often a very painful process. >>> "If this is true of your project, integrate every time somebody checks in, and do it from the start of the project. >>> If testing is a painful process that occurs just before release, don?t do it at the end. Instead, do it continually from the beginning of the project." > > I like the term "Continuous Delivery" as compared to "Continuous Integration" since Integration is such as loaded term in our current infrastructure. > > I also like +100 the comment about testing ... > Also... continuous delivery of openjdk builds, preferably labeled with the changeset id corresponding to the tip of the build. That will make it much easier for developers to verify a fix. I don't like saying "I have fixed the issue in tl, but you will have to wait a week or so until build XXX appears" (so "old skool") thus making it harder to spin faster and get feedback. Paul. From marcus.lagergren at oracle.com Wed Dec 4 03:47:35 2013 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 4 Dec 2013 12:47:35 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <6BED40BF-6259-4AE3-80EC-E26D088D27C1@oracle.com> References: <5290D912.7090002@oracle.com> <52936A88.2010306@oracle.com> <5294D69D.3070401@oracle.com> <5295B2B9.9080003@oracle.com> <529C1752.8040401@oracle.com> <529CE109.2090202@oracle.com> <6BED40BF-6259-4AE3-80EC-E26D088D27C1@oracle.com> Message-ID: <8271E54D-894F-43AA-B900-577F294F6F63@oracle.com> > > Also... continuous delivery of openjdk builds, preferably labeled with the changeset id corresponding to the tip of the build. > > That will make it much easier for developers to verify a fix. I don't like saying "I have fixed the issue in tl, but you will have to wait a week or so until build XXX appears" (so "old skool") thus making it harder to spin faster and get feedback. > > Paul. +1000 on this. /M From magnus.ihse.bursie at oracle.com Wed Dec 4 05:38:15 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 04 Dec 2013 14:38:15 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529E2744.7070105@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> Message-ID: <529F3047.7000706@oracle.com> On 2013-12-03 19:47, Joe Darcy wrote: > The separate repositories for corba, jaxp, and jax-ws were put in > place to reflect these differences in code origin and handling; > however, I agree it is worthwhile to contemplate a repository > consolidation, at least for all the libraries-related repos (jdk, > corba, jaxp, jaxws). Build-related changes touches several repos more often than not. And it's always a pain. I can accept pain if it's neccessary, but this particular pain feels so ... eh... *not* neccessary. I whole-heartedly support any suggestion of minimizing the number of repos in the forest. /Magnus From magnus.ihse.bursie at oracle.com Wed Dec 4 05:41:35 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 04 Dec 2013 14:41:35 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529EF69E.8020902@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> Message-ID: <529F310F.4030802@oracle.com> On 2013-12-04 10:32, Alan Bateman wrote: > On 03/12/2013 18:47, Joe Darcy wrote: >> : >> >> The separate repositories for corba, jaxp, and jax-ws were put in >> place to reflect these differences in code origin and handling; >> however, I agree it is worthwhile to contemplate a repository >> consolidation, at least for all the libraries-related repos (jdk, >> corba, jaxp, jaxws). > I agree that jaxp and corba should be looked at. That would also help > with a number of awkward circular dependencies and build issues (the > code in these two repositories really needs to be in the same big > compilation unit as the code in the jdk repository, at least until > we/if get to the point where the JDK is compiled as modules). > Furthermore, the timing is probably right for JAXP as it has proposed > to discontinue its standalone form and this opens the door to taking > advantage of new Java Language features and APIs. From a build perspective, jaxp and corba should, as you say, preferably be compiled as part of the JDK. We are doing unnecessary build steps, as well as missing out on build optimization possibilities, due to this split in different repos. > I'm less sure about the jaxws repository as this is the transformation > of code from a number of upstream projects. Having it in its own > repository makes it a bit more obvious that we shouldn't be changing > anything in that code (as it will be trashed by updates from > upstream). Also it does not need to be compiled with the code in the > jdk repository and actually doesn't need to be packaged in rt.jar > either (but that is a separate topic). If nothing else, then I think > that the code in the jaxws repository should be compiled after the jdk > repository to avoid some of the boot cycle build issues that > periodically arises with big updates from upstream. So if we really don't need it for jdk, nor the rt.jar -- then what use is it? :-) Even if I know how jaxws is *built*, I don't really have a clue what it's *for*. :-) Currently, we have a dependency on jaxws from jdk in the build system. Right now, I can't see why, since as you say, it works just as well to compile after the JDK (if you hack away the artifical dependencies currently in place in the build system). Don't know why we're not doing it that way already. Anyway. From your argument I think it follows that jaxws should be in a separate subdirectory from the rest of the libraries, but I don't think that it neccessarily follows that it needs to be a separate repository. /Magnus From dalibor.topic at oracle.com Wed Dec 4 06:05:23 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 04 Dec 2013 15:05:23 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F310F.4030802@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> Message-ID: <529F36A3.6080901@oracle.com> On 12/4/13 2:41 PM, Magnus Ihse Bursie wrote: > Anyway. From your argument I think it follows that jaxws should be in a separate subdirectory from the rest of the libraries, but I don't think that it neccessarily follows that it needs to be a separate repository. Yeah - I think an 'UPSTREAMCOPY' [0] (sub)directory would be a better choice to host such code then a separate repository. cheers, dalibor topic [0] Or 'DoAsMCHammerSays' or whatever a good directory name is. -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From lance.andersen at oracle.com Wed Dec 4 06:23:47 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Wed, 4 Dec 2013 09:23:47 -0500 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F310F.4030802@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> Message-ID: <915EC759-287F-4474-A964-4953EAF09800@oracle.com> Jaxws needs to be its own repository as it is being revised/enhanced for java ee schedules and until that need goes away it would not be a good idea to consolidate Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad On Dec 4, 2013, at 8:41 AM, Magnus Ihse Bursie wrote: > On 2013-12-04 10:32, Alan Bateman wrote: >> On 03/12/2013 18:47, Joe Darcy wrote: >>> : >>> >>> The separate repositories for corba, jaxp, and jax-ws were put in place to reflect these differences in code origin and handling; however, I agree it is worthwhile to contemplate a repository consolidation, at least for all the libraries-related repos (jdk, corba, jaxp, jaxws). >> I agree that jaxp and corba should be looked at. That would also help with a number of awkward circular dependencies and build issues (the code in these two repositories really needs to be in the same big compilation unit as the code in the jdk repository, at least until we/if get to the point where the JDK is compiled as modules). Furthermore, the timing is probably right for JAXP as it has proposed to discontinue its standalone form and this opens the door to taking advantage of new Java Language features and APIs. > > From a build perspective, jaxp and corba should, as you say, preferably be compiled as part of the JDK. We are doing unnecessary build steps, as well as missing out on build optimization possibilities, due to this split in different repos. > >> I'm less sure about the jaxws repository as this is the transformation of code from a number of upstream projects. Having it in its own repository makes it a bit more obvious that we shouldn't be changing anything in that code (as it will be trashed by updates from upstream). Also it does not need to be compiled with the code in the jdk repository and actually doesn't need to be packaged in rt.jar either (but that is a separate topic). If nothing else, then I think that the code in the jaxws repository should be compiled after the jdk repository to avoid some of the boot cycle build issues that periodically arises with big updates from upstream. > So if we really don't need it for jdk, nor the rt.jar -- then what use is it? :-) Even if I know how jaxws is *built*, I don't really have a clue what it's *for*. :-) > > Currently, we have a dependency on jaxws from jdk in the build system. Right now, I can't see why, since as you say, it works just as well to compile after the JDK (if you hack away the artifical dependencies currently in place in the build system). Don't know why we're not doing it that way already. > > Anyway. From your argument I think it follows that jaxws should be in a separate subdirectory from the rest of the libraries, but I don't think that it neccessarily follows that it needs to be a separate repository. > > /Magnus From Alan.Bateman at oracle.com Wed Dec 4 07:52:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Dec 2013 15:52:49 +0000 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F310F.4030802@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> Message-ID: <529F4FD1.5080102@oracle.com> On 04/12/2013 13:41, Magnus Ihse Bursie wrote: > So if we really don't need it for jdk, nor the rt.jar -- then what use > is it? :-) Even if I know how jaxws is *built*, I don't really have a > clue what it's *for*. :-) The APIs in the jaxws repository are part of Java SE and so we do need to build it, it's just each of them (JAX-WS, JAXB, SAAJ, ..) lead a double life as a standalone technology. Many of the app servers ship with newer implementations and don't use the versions that are in the JRE. > > Currently, we have a dependency on jaxws from jdk in the build system. > Right now, I can't see why, since as you say, it works just as well to > compile after the JDK (if you hack away the artifical dependencies > currently in place in the build system). Don't know why we're not > doing it that way already. I believe that things are built in this order to match the old build (to get identical bits, modulo the compare script). The old build is gone now so there is an opportunity to fix a number of things. If there are changes to the number of repositories then maybe it's the perfect storm to fix this one too. -Alan. From coleen.phillimore at oracle.com Wed Dec 4 08:17:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 04 Dec 2013 11:17:02 -0500 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F4FD1.5080102@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> Message-ID: <529F557E.5050009@oracle.com> As everyone probably knows, for hotspot, we run JPRT as a integration gate. It builds and runs some last-ditch tests on all platforms. We disallow checkins that fail this test step. Other diverse tests are also required for changes, not in JPRT. If we make jdk + hotspot changes, how do we check this in to the jdk9 forest? Who is making the JPRT (or other equivalent integration testing tool) changes so that we do not lose this test step? Sorry if this is embedded in this long thread. I assume JPRT (or equivalent new thing) would build jdk+hotspot on all platforms and if hotspot changes, run the hotspot integration tests currently defined in the hotspot jprt.properties file. All hotspot integrations would have to be full jdk+hotspot jobs to get the latest jdk changes (rather than last promoted jdk) because there may be necessary jdk changes in the n-1th integration. Is someone working on these changes that are needed in order to open this repository? Thanks, Coleen From serguei.spitsyn at oracle.com Wed Dec 4 08:31:55 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 04 Dec 2013 08:31:55 -0800 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F557E.5050009@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> Message-ID: <529F58FB.8000101@oracle.com> +1 I was about to ask similar questions related to hotspot integrations through JPRT. Thanks! Serguei On 12/4/13 8:17 AM, Coleen Phillimore wrote: > > As everyone probably knows, for hotspot, we run JPRT as a integration > gate. It builds and runs some last-ditch tests on all platforms. > We disallow checkins that fail this test step. Other diverse tests are > also required for changes, not in JPRT. > > If we make jdk + hotspot changes, how do we check this in to the jdk9 > forest? Who is making the JPRT (or other equivalent integration > testing tool) changes so that we do not lose this test step? Sorry > if this is embedded in this long thread. > > I assume JPRT (or equivalent new thing) would build jdk+hotspot on all > platforms and if hotspot changes, run the hotspot integration tests > currently defined in the hotspot jprt.properties file. All hotspot > integrations would have to be full jdk+hotspot jobs to get the latest > jdk changes (rather than last promoted jdk) because there may be > necessary jdk changes in the n-1th integration. Is someone working > on these changes that are needed in order to open this repository? > > Thanks, > Coleen > > From jeremymanson at google.com Wed Dec 4 09:36:56 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 4 Dec 2013 09:36:56 -0800 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F58FB.8000101@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> <529F58FB.8000101@oracle.com> Message-ID: This may not be the thread to bring up this topic, but, AFAIK, external contributors still can't run JPRT. I guess that doesn't really change the need to run it as part of continuous integration, but it makes it slightly more frustrating to contribute. Perhaps making it available externally could be done together with whatever jiggering is required to get it integrated into the continuous testing? Jeremy On Wed, Dec 4, 2013 at 8:31 AM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > +1 > I was about to ask similar questions related to hotspot integrations > through JPRT. > > Thanks! > Serguei > > > > On 12/4/13 8:17 AM, Coleen Phillimore wrote: > >> >> As everyone probably knows, for hotspot, we run JPRT as a integration >> gate. It builds and runs some last-ditch tests on all platforms. We >> disallow checkins that fail this test step. Other diverse tests are also >> required for changes, not in JPRT. >> >> If we make jdk + hotspot changes, how do we check this in to the jdk9 >> forest? Who is making the JPRT (or other equivalent integration testing >> tool) changes so that we do not lose this test step? Sorry if this is >> embedded in this long thread. >> >> I assume JPRT (or equivalent new thing) would build jdk+hotspot on all >> platforms and if hotspot changes, run the hotspot integration tests >> currently defined in the hotspot jprt.properties file. All hotspot >> integrations would have to be full jdk+hotspot jobs to get the latest jdk >> changes (rather than last promoted jdk) because there may be necessary jdk >> changes in the n-1th integration. Is someone working on these changes >> that are needed in order to open this repository? >> >> Thanks, >> Coleen >> >> >> > From joe.darcy at oracle.com Wed Dec 4 09:56:13 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 04 Dec 2013 09:56:13 -0800 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F557E.5050009@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> Message-ID: <529F6CBD.90309@oracle.com> On 12/04/2013 08:17 AM, Coleen Phillimore wrote: > > As everyone probably knows, for hotspot, we run JPRT as a integration > gate. It builds and runs some last-ditch tests on all platforms. > We disallow checkins that fail this test step. Other diverse tests are > also required for changes, not in JPRT. > > If we make jdk + hotspot changes, how do we check this in to the jdk9 > forest? Who is making the JPRT (or other equivalent integration > testing tool) changes so that we do not lose this test step? Sorry > if this is embedded in this long thread. > > I assume JPRT (or equivalent new thing) would build jdk+hotspot on all > platforms and if hotspot changes, run the hotspot integration tests > currently defined in the hotspot jprt.properties file. All hotspot > integrations would have to be full jdk+hotspot jobs to get the latest > jdk changes (rather than last promoted jdk) because there may be > necessary jdk changes in the n-1th integration. Is someone working > on these changes that are needed in order to open this repository? > > Thanks, > Coleen > > Hi Coleen, This issue was raised before in some internal discussions. IIRC, there was a workaround without changing jprt. In any case, we could still change the graph of forests first and initially do HotSpot + libs fixes as we do today and still get latency benefits before any needed adjustments to jprt are made. Thanks, -Joe From martijnverburg at gmail.com Wed Dec 4 10:00:57 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 4 Dec 2013 18:00:57 +0000 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> <529F58FB.8000101@oracle.com> Message-ID: +1 - we're hoping to start running some basic CI infrastructure Q1 next for the hackdays we run (typically a number of small patches come out of it that we want tested *before* we go bothering reviewer's time). Cheers, Martijn On 4 December 2013 17:36, Jeremy Manson wrote: > This may not be the thread to bring up this topic, but, AFAIK, external > contributors still can't run JPRT. I guess that doesn't really change the > need to run it as part of continuous integration, but it makes it slightly > more frustrating to contribute. > > Perhaps making it available externally could be done together with whatever > jiggering is required to get it integrated into the continuous testing? > > Jeremy > > > On Wed, Dec 4, 2013 at 8:31 AM, serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > > > +1 > > I was about to ask similar questions related to hotspot integrations > > through JPRT. > > > > Thanks! > > Serguei > > > > > > > > On 12/4/13 8:17 AM, Coleen Phillimore wrote: > > > >> > >> As everyone probably knows, for hotspot, we run JPRT as a integration > >> gate. It builds and runs some last-ditch tests on all platforms. We > >> disallow checkins that fail this test step. Other diverse tests are also > >> required for changes, not in JPRT. > >> > >> If we make jdk + hotspot changes, how do we check this in to the jdk9 > >> forest? Who is making the JPRT (or other equivalent integration testing > >> tool) changes so that we do not lose this test step? Sorry if this is > >> embedded in this long thread. > >> > >> I assume JPRT (or equivalent new thing) would build jdk+hotspot on all > >> platforms and if hotspot changes, run the hotspot integration tests > >> currently defined in the hotspot jprt.properties file. All hotspot > >> integrations would have to be full jdk+hotspot jobs to get the latest > jdk > >> changes (rather than last promoted jdk) because there may be necessary > jdk > >> changes in the n-1th integration. Is someone working on these changes > >> that are needed in order to open this repository? > >> > >> Thanks, > >> Coleen > >> > >> > >> > > > From coleen.phillimore at oracle.com Wed Dec 4 11:55:53 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 04 Dec 2013 14:55:53 -0500 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F6CBD.90309@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> <529F6CBD.90309@oracle.com> Message-ID: <529F88C9.2010709@oracle.com> On 12/4/2013 12:56 PM, Joe Darcy wrote: > On 12/04/2013 08:17 AM, Coleen Phillimore wrote: >> >> As everyone probably knows, for hotspot, we run JPRT as a integration >> gate. It builds and runs some last-ditch tests on all platforms. >> We disallow checkins that fail this test step. Other diverse tests >> are also required for changes, not in JPRT. >> >> If we make jdk + hotspot changes, how do we check this in to the jdk9 >> forest? Who is making the JPRT (or other equivalent integration >> testing tool) changes so that we do not lose this test step? Sorry >> if this is embedded in this long thread. >> >> I assume JPRT (or equivalent new thing) would build jdk+hotspot on >> all platforms and if hotspot changes, run the hotspot integration >> tests currently defined in the hotspot jprt.properties file. All >> hotspot integrations would have to be full jdk+hotspot jobs to get >> the latest jdk changes (rather than last promoted jdk) because there >> may be necessary jdk changes in the n-1th integration. Is someone >> working on these changes that are needed in order to open this >> repository? >> >> Thanks, >> Coleen >> >> > > Hi Coleen, > > This issue was raised before in some internal discussions. IIRC, there > was a workaround without changing jprt. > > In any case, we could still change the graph of forests first and > initially do HotSpot + libs fixes as we do today and still get latency > benefits before any needed adjustments to jprt are made. So we cannot make jdk+hotspot changes to the same forest? We still have latency only it's reduced? thanks, Coleen (sorry for asking on the open list - I don't know the closed alias) > > Thanks, > > -Joe From joe.darcy at oracle.com Wed Dec 4 12:04:41 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 04 Dec 2013 12:04:41 -0800 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F88C9.2010709@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> <529F6CBD.90309@oracle.com> <529F88C9.2010709@oracle.com> Message-ID: <529F8AD9.8060603@oracle.com> On 12/04/2013 11:55 AM, Coleen Phillimore wrote: > On 12/4/2013 12:56 PM, Joe Darcy wrote: >> On 12/04/2013 08:17 AM, Coleen Phillimore wrote: >>> >>> As everyone probably knows, for hotspot, we run JPRT as a >>> integration gate. It builds and runs some last-ditch tests on all >>> platforms. We disallow checkins that fail this test step. Other >>> diverse tests are also required for changes, not in JPRT. >>> >>> If we make jdk + hotspot changes, how do we check this in to the >>> jdk9 forest? Who is making the JPRT (or other equivalent >>> integration testing tool) changes so that we do not lose this test >>> step? Sorry if this is embedded in this long thread. >>> >>> I assume JPRT (or equivalent new thing) would build jdk+hotspot on >>> all platforms and if hotspot changes, run the hotspot integration >>> tests currently defined in the hotspot jprt.properties file. All >>> hotspot integrations would have to be full jdk+hotspot jobs to get >>> the latest jdk changes (rather than last promoted jdk) because there >>> may be necessary jdk changes in the n-1th integration. Is someone >>> working on these changes that are needed in order to open this >>> repository? >>> >>> Thanks, >>> Coleen >>> >>> >> >> Hi Coleen, >> >> This issue was raised before in some internal discussions. IIRC, >> there was a workaround without changing jprt. >> >> In any case, we could still change the graph of forests first and >> initially do HotSpot + libs fixes as we do today and still get >> latency benefits before any needed adjustments to jprt are made. > > So we cannot make jdk+hotspot changes to the same forest? We still > have latency only it's reduced? > thanks, > Coleen > > If the new JDK 9 forest structure were to be put in place today, we might not be able to easily do jdk repo + hospot pushes. However, even in that case, we would still have an easier time propagating changes. Since one goal of this rearrangement is to do coordinated pushes, any needed adjustments in jprt to support this should be made after the new forest structure is in effect. -Joe From coleen.phillimore at oracle.com Wed Dec 4 12:07:18 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 04 Dec 2013 15:07:18 -0500 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F8AD9.8060603@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> <529F6CBD.90309@oracle.com> <529F88C9.2010709@oracle.com> <529F8AD9.8060603@oracle.com> Message-ID: <529F8B76.6040500@oracle.com> On 12/4/2013 3:04 PM, Joe Darcy wrote: > On 12/04/2013 11:55 AM, Coleen Phillimore wrote: >> On 12/4/2013 12:56 PM, Joe Darcy wrote: >>> On 12/04/2013 08:17 AM, Coleen Phillimore wrote: >>>> >>>> As everyone probably knows, for hotspot, we run JPRT as a >>>> integration gate. It builds and runs some last-ditch tests on all >>>> platforms. We disallow checkins that fail this test step. Other >>>> diverse tests are also required for changes, not in JPRT. >>>> >>>> If we make jdk + hotspot changes, how do we check this in to the >>>> jdk9 forest? Who is making the JPRT (or other equivalent >>>> integration testing tool) changes so that we do not lose this test >>>> step? Sorry if this is embedded in this long thread. >>>> >>>> I assume JPRT (or equivalent new thing) would build jdk+hotspot on >>>> all platforms and if hotspot changes, run the hotspot integration >>>> tests currently defined in the hotspot jprt.properties file. All >>>> hotspot integrations would have to be full jdk+hotspot jobs to get >>>> the latest jdk changes (rather than last promoted jdk) because >>>> there may be necessary jdk changes in the n-1th integration. Is >>>> someone working on these changes that are needed in order to open >>>> this repository? >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >>> Hi Coleen, >>> >>> This issue was raised before in some internal discussions. IIRC, >>> there was a workaround without changing jprt. >>> >>> In any case, we could still change the graph of forests first and >>> initially do HotSpot + libs fixes as we do today and still get >>> latency benefits before any needed adjustments to jprt are made. >> >> So we cannot make jdk+hotspot changes to the same forest? We still >> have latency only it's reduced? >> thanks, >> Coleen >> >> > > If the new JDK 9 forest structure were to be put in place today, we > might not be able to easily do jdk repo + hospot pushes. However, even > in that case, we would still have an easier time propagating changes. > > Since one goal of this rearrangement is to do coordinated pushes, any > needed adjustments in jprt to support this should be made after the > new forest structure is in effect. Ok. Thanks! Coleen > > -Joe > From magnus.ihse.bursie at oracle.com Thu Dec 5 01:35:34 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 05 Dec 2013 10:35:34 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F4FD1.5080102@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> Message-ID: <52A048E6.6030606@oracle.com> On 2013-12-04 16:52, Alan Bateman wrote: >> Currently, we have a dependency on jaxws from jdk in the build >> system. Right now, I can't see why, since as you say, it works just >> as well to compile after the JDK (if you hack away the artifical >> dependencies currently in place in the build system). Don't know why >> we're not doing it that way already. > > I believe that things are built in this order to match the old build > (to get identical bits, modulo the compare script). The old build is > gone now so there is an opportunity to fix a number of things. If > there are changes to the number of repositories then maybe it's the > perfect storm to fix this one too. That is likely something we want to change in jdk9 regardless of the outcome of this discussion. It does not matter greatly, but for developers who just want to build the jdk target, it will get a little bit speedier if jaxws is built after the jdk, like the demos. I opened https://bugs.openjdk.java.net/browse/JDK-8029591 for this. Thank you for bringing this to my attention! /Magnus From fweimer at redhat.com Thu Dec 5 07:18:59 2013 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 05 Dec 2013 16:18:59 +0100 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <915EC759-287F-4474-A964-4953EAF09800@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <915EC759-287F-4474-A964-4953EAF09800@oracle.com> Message-ID: <52A09963.7070409@redhat.com> On 12/04/2013 03:23 PM, Lance @ Oracle wrote: > Jaxws needs to be its own repository as it is being revised/enhanced for java ee schedules and until that need goes away it would not be a good idea to consolidate Could you explain how this is important to you, considering that the master repository appears to be a separate from OpenJDK and whose contents is imported into OpenJDK only in bulk? Do you regularly important the OpenJDK changes into the master repository? -- Florian Weimer / Red Hat Product Security Team From mark.reinhold at oracle.com Thu Dec 5 09:09:53 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Dec 2013 09:09:53 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529D9300.605@oracle.com> References: <5290D912.7090002@oracle.com>, <529D2B69.3080903@oracle.com>, <529D9300.605@oracle.com> Message-ID: <20131205090953.968719@eggemoggin.niobe.net> 2013/12/2 16:14 -0800, joe.darcy at oracle.com: > On 12/02/2013 04:52 PM, Lana Steuck wrote: >> On 12/02/2013 11:38 AM, mark.reinhold at oracle.com wrote: >>> That's no doubt a good thing, but are we confident that we'll be able >>> to do such an integration every week, including any necessary manual >>> testing of client code? If not then it seems we need a separate >>> client forest that feeds into the dev forest after appropriate >>> testing, just like the HotSpot forests. - Mark >> >> It seems that it would depend on SQE resources. If SQE could perform >> manual client testing of the pre-integration build weekly, then we >> could do weekly integrations of jdk9-dev. > > A few more thoughts on client library code. > > ... > > My strong preference is to start JDK 9 *without* a forest dedicated to > client libs changes and only add such a forest if that arrangement > proves unworkable in practice. Fewer forests means testing efforts can > be more focused. Based on what Yuri and Artem said elsewhere in this thread, it sounds like the manual pre-integration testing of client code is light enough to support this approach, so let's go with it. - Mark From mark.reinhold at oracle.com Thu Dec 5 09:39:52 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Dec 2013 09:39:52 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529D9837.4050802@oracle.com> References: <5290D912.7090002@oracle.com>, <20131202115035.797919@eggemoggin.niobe.net>, <529D9837.4050802@oracle.com> Message-ID: <20131205093952.628217@eggemoggin.niobe.net> 2013/12/2 16:37 -0800, joe.darcy at oracle.com: > On 12/02/2013 11:50 AM, mark.reinhold at oracle.com wrote: >> Can you say more about your discomfort? Eliminating the master/dev >> distinction is another good simplification, I think, and if we're >> going to shake things up anyway then now is a good time to do it. >> >> Is your concern mainly that consumers of the master forest will have >> to change their habits, and always look for the current build tag? >> >> One way to make that easier would be to define another tag, say >> jdk9-current, that also tags the latest jdk9-bXXX changesets. > > I would expect some hiccups transitioning to the new model; dev *should* > be stable, but a problem may be found later than desired, etc. Having a > separate master forest, and the potential to make out-of-band > integrations to it, allows an easy remedy to such a situation by doing > what we do know. We can make an out-of-band fix to a unified master/dev forest simply by updating the jdk9-current tag: $ hg clone -r jdk9-current http://hg.openjdk.java.net/jdk9/jdk9/$REPO $ cd $REPO $ # ... apply fix ... $ hg ci -m $MESSAGE $ hg tag -f jdk9-current jdk9-$BUILD $ # ... pull and merge if needed ... $ hg push The weekly integration process would work in the same way, except it would tag every repo in the forest. The only transition required for consumers who want the latest stable and tested "master" code is to specify the jdk9-current tag when doing a clone or a pull: $ hg tclone -r jdk9-current http://hg.openjdk.java.net/jdk9/jdk9 (This example uses John Coomes's forthcoming trees extension [1]; it should be simple to modify get_source.sh and common/bin/hgforest.sh to pull a specific tag as well.) - Mark [1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2013-April/000009.html From philip.race at oracle.com Thu Dec 5 10:10:32 2013 From: philip.race at oracle.com (Phil Race) Date: Thu, 05 Dec 2013 10:10:32 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <20131205090953.968719@eggemoggin.niobe.net> References: <5290D912.7090002@oracle.com>, <529D2B69.3080903@oracle.com>, <529D9300.605@oracle.com> <20131205090953.968719@eggemoggin.niobe.net> Message-ID: <52A0C198.9030405@oracle.com> I don't think what Artem said is quite correct. SQE may not do manual testing But the integrator certainly does. The final steps of our integration process has always included certain manual tests (applets, SwingSet, Java2Demo) on all the platforms (Windows, Linux, Solaris and now Mac) on the final built bits. We will need to maintain that process. Whilst hotspot and language changes may need to coordinate to be in the same place sooner rather than later there is no such need for client changes. So no benefit accrues from a shared forest there. -phil. On 12/5/2013 9:09 AM, mark.reinhold at oracle.com wrote: > 2013/12/2 16:14 -0800, joe.darcy at oracle.com: >> On 12/02/2013 04:52 PM, Lana Steuck wrote: >>> On 12/02/2013 11:38 AM, mark.reinhold at oracle.com wrote: >>>> That's no doubt a good thing, but are we confident that we'll be able >>>> to do such an integration every week, including any necessary manual >>>> testing of client code? If not then it seems we need a separate >>>> client forest that feeds into the dev forest after appropriate >>>> testing, just like the HotSpot forests. - Mark >>> It seems that it would depend on SQE resources. If SQE could perform >>> manual client testing of the pre-integration build weekly, then we >>> could do weekly integrations of jdk9-dev. >> A few more thoughts on client library code. >> >> ... >> >> My strong preference is to start JDK 9 *without* a forest dedicated to >> client libs changes and only add such a forest if that arrangement >> proves unworkable in practice. Fewer forests means testing efforts can >> be more focused. > Based on what Yuri and Artem said elsewhere in this thread, it sounds > like the manual pre-integration testing of client code is light enough > to support this approach, so let's go with it. > > - Mark From mark.reinhold at oracle.com Thu Dec 5 10:23:33 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Dec 2013 10:23:33 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <52A0C198.9030405@oracle.com> References: <5290D912.7090002@oracle.com>, <20131205090953.968719@eggemoggin.niobe.net>, <52A0C198.9030405@oracle.com> Message-ID: <20131205102333.258365@eggemoggin.niobe.net> 2013/12/5 2:10 -0800, philip.race at oracle.com: > I don't think what Artem said is quite correct. SQE may not do manual > testing But the integrator certainly does. The final steps of our > integration process has always included certain manual tests (applets, > SwingSet, Java2Demo) on all the platforms (Windows, Linux, Solaris and > now Mac) on the final built bits. We will need to maintain that > process. Lana -- Can you handle doing these manual tests once a week? > Whilst hotspot and language changes may need to coordinate to be in > the same place sooner rather than later there is no such need for > client changes. So no benefit accrues from a shared forest there. The need for coordinated changes may be lower, but there are still benefits in terms of mixing code earlier and focusing the integration and testing process. - Mark From daniel.daugherty at oracle.com Thu Dec 5 15:03:52 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 05 Dec 2013 16:03:52 -0700 Subject: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529F6CBD.90309@oracle.com> References: <5290D912.7090002@oracle.com> <52935368.8050408@oracle.com> <529C14C8.8000105@oracle.com> <7FE8FC3D-CBC2-440E-B11F-7CAF5F504244@oracle.com> <529E2744.7070105@oracle.com> <529EF69E.8020902@oracle.com> <529F310F.4030802@oracle.com> <529F4FD1.5080102@oracle.com> <529F557E.5050009@oracle.com> <529F6CBD.90309@oracle.com> Message-ID: <52A10658.1000607@oracle.com> On 12/4/13 10:56 AM, Joe Darcy wrote: > On 12/04/2013 08:17 AM, Coleen Phillimore wrote: >> >> As everyone probably knows, for hotspot, we run JPRT as a integration >> gate. It builds and runs some last-ditch tests on all platforms. >> We disallow checkins that fail this test step. Other diverse tests >> are also required for changes, not in JPRT. >> >> If we make jdk + hotspot changes, how do we check this in to the jdk9 >> forest? Who is making the JPRT (or other equivalent integration >> testing tool) changes so that we do not lose this test step? Sorry >> if this is embedded in this long thread. >> >> I assume JPRT (or equivalent new thing) would build jdk+hotspot on >> all platforms and if hotspot changes, run the hotspot integration >> tests currently defined in the hotspot jprt.properties file. All >> hotspot integrations would have to be full jdk+hotspot jobs to get >> the latest jdk changes (rather than last promoted jdk) because there >> may be necessary jdk changes in the n-1th integration. Is someone >> working on these changes that are needed in order to open this >> repository? >> >> Thanks, >> Coleen >> >> > > Hi Coleen, > > This issue was raised before in some internal discussions. IIRC, there > was a workaround without changing jprt. More precisely, the '-forest' option "works" to build and test a 'jdk' repo plus a 'hotspot' repo with a couple of (big) caveats: - embedded builds aren't done since the 'jdk' repo does not yet support building on embedded - the tests that are executed are the 'jdk' repo tests and not the 'hotspot' repo tests The "work around" that Alejandro and John C currently use is to do a pair of jobs. One is a HotSpot job to get all the builds and HotSpot specific testing done along with the push. The second job is a control build with all the repos necessary to build the combined 'jdk' and 'hotspot' changes together. I believe the second job is used for PIT. Painful? You bet. Dan > > In any case, we could still change the graph of forests first and > initially do HotSpot + libs fixes as we do today and still get latency > benefits before any needed adjustments to jprt are made. > > Thanks, > > -Joe From Alan.Bateman at oracle.com Fri Dec 6 01:45:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Dec 2013 09:45:21 +0000 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <529DD2CB.7080101@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529DD2CB.7080101@oracle.com> Message-ID: <52A19CB1.7010803@oracle.com> On 03/12/2013 12:47, Yuri Nesterenko wrote: > : > > In fact, I think it may be even easier for SQE, here's a paradox. > We hope to have nightly builds established, and thus be prepared for PIT > very well; weekly routine is easier to plan in advance (and SQE is all > about planning); finally, we don't really do full-profile manual > testing for PIT. It's all automated + some sanity checks + > cursory verification of actual fixes. This last task will be smaller > if do it weekly. > I'm curious about the automated part. For the tests in the jdk repository then is it all of tests in the jdk_desktop group (see TEST.groups) or a subset of them? -Alan From yuri.nesterenko at oracle.com Fri Dec 6 01:56:53 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 06 Dec 2013 13:56:53 +0400 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <52A19CB1.7010803@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529DD2CB.7080101@oracle.com> <52A19CB1.7010803@oracle.com> Message-ID: <52A19F65.6000506@oracle.com> On 12/06/2013 01:45 PM, Alan Bateman wrote: > On 03/12/2013 12:47, Yuri Nesterenko wrote: >> : >> >> In fact, I think it may be even easier for SQE, here's a paradox. >> We hope to have nightly builds established, and thus be prepared for PIT >> very well; weekly routine is easier to plan in advance (and SQE is all >> about planning); finally, we don't really do full-profile manual >> testing for PIT. It's all automated + some sanity checks + >> cursory verification of actual fixes. This last task will be smaller >> if do it weekly. >> > I'm curious about the automated part. For the tests in the jdk > repository then is it all of tests in the jdk_desktop group (see > TEST.groups) or a subset of them? > > -Alan > There's rather elaborate division procedure for regression tests (the tests in jdk repositories). I'll send you a link to an internal wiki page about this if you wish. Apart from these, we run separate functional suites; different people own different parts of this. I personally run 2D functional and do some sanity checks. -yan From Alan.Bateman at oracle.com Fri Dec 6 02:55:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Dec 2013 10:55:22 +0000 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <52A19F65.6000506@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529DD2CB.7080101@oracle.com> <52A19CB1.7010803@oracle.com> <52A19F65.6000506@oracle.com> Message-ID: <52A1AD1A.7060802@oracle.com> On 06/12/2013 09:56, Yuri Nesterenko wrote: > : > > There's rather elaborate division procedure for regression tests > (the tests in jdk repositories). I'll send you a link > to an internal wiki page about this if you wish. Thanks, although it might be useful for the discussion here to understand if there are any technical reasons for the slice 'n dice. For example, is it necessary to do this because the tests take a long time? For the areas that you run then you have a sense for reliability of the tests? -Alan. From yuri.nesterenko at oracle.com Fri Dec 6 03:11:23 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 06 Dec 2013 15:11:23 +0400 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <52A1AD1A.7060802@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529DD2CB.7080101@oracle.com> <52A19CB1.7010803@oracle.com> <52A19F65.6000506@oracle.com> <52A1AD1A.7060802@oracle.com> Message-ID: <52A1B0DB.5020503@oracle.com> On 12/06/2013 02:55 PM, Alan Bateman wrote: > On 06/12/2013 09:56, Yuri Nesterenko wrote: >> : >> >> There's rather elaborate division procedure for regression tests >> (the tests in jdk repositories). I'll send you a link >> to an internal wiki page about this if you wish. > Thanks, although it might be useful for the discussion here to > understand if there are any technical reasons for the slice 'n dice. For > example, is it necessary to do this because the tests take a long time? > For the areas that you run then you have a sense for reliability of the > tests? > > -Alan. There are some technical reasons like necessity for certain tests to run headful on machines with printers etc. -- plus obviously, you can run different pieces on different farm machines in parallel. And yes, client tests seems reliable enough: more so than farm environment :-) -yan From Alan.Bateman at oracle.com Fri Dec 6 03:29:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Dec 2013 11:29:05 +0000 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <52A1B0DB.5020503@oracle.com> References: <5290D912.7090002@oracle.com>, <5291EE5A.503@oracle.com>, <5292A4AC.7090700@oracle.com> <20131202113845.390471@eggemoggin.niobe.net> <529D2B69.3080903@oracle.com> <529DD2CB.7080101@oracle.com> <52A19CB1.7010803@oracle.com> <52A19F65.6000506@oracle.com> <52A1AD1A.7060802@oracle.com> <52A1B0DB.5020503@oracle.com> Message-ID: <52A1B501.9040400@oracle.com> On 06/12/2013 11:11, Yuri Nesterenko wrote: > > There are some technical reasons like necessity for certain tests to > run headful on machines with printers etc. -- plus obviously, you can > run different pieces on different farm machines in parallel. > > And yes, client tests seems reliable enough: more so than > farm environment :-) Thanks for the insight. Just on "seems reliable enough". Is this strong enough to say that the result of a test run can be expressed as a boolean? -Alan From mark.reinhold at oracle.com Mon Dec 9 14:52:05 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 09 Dec 2013 14:52:05 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <20131205093952.628217@eggemoggin.niobe.net> References: <5290D912.7090002@oracle.com>, <529D9837.4050802@oracle.com>, <20131205093952.628217@eggemoggin.niobe.net> Message-ID: <20131209145205.172284@eggemoggin.niobe.net> 2013/12/5 1:39 -0800, mark.reinhold at oracle.com: > 2013/12/2 16:37 -0800, joe.darcy at oracle.com: >> On 12/02/2013 11:50 AM, mark.reinhold at oracle.com wrote: >>> Can you say more about your discomfort? Eliminating the master/dev >>> distinction is another good simplification, I think, and if we're >>> going to shake things up anyway then now is a good time to do it. >> >> I would expect some hiccups transitioning to the new model; dev *should* >> be stable, but a problem may be found later than desired, etc. Having a >> separate master forest, and the potential to make out-of-band >> integrations to it, allows an easy remedy to such a situation by doing >> what we do know. > > We can make an out-of-band fix to a unified master/dev forest simply by > updating the jdk9-current tag: > > ... On further thought, I withdraw my suggestion that we eliminate the master forest in JDK 9 at this time. I think this is worth exploring further, but right now it's more important to get the JDK 9 forests up and running. - Mark From lana.steuck at oracle.com Mon Dec 9 16:01:55 2013 From: lana.steuck at oracle.com (Lana Steuck) Date: Mon, 09 Dec 2013 16:01:55 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <20131205102333.258365@eggemoggin.niobe.net> References: <5290D912.7090002@oracle.com>, <20131205090953.968719@eggemoggin.niobe.net>, <52A0C198.9030405@oracle.com> <20131205102333.258365@eggemoggin.niobe.net> Message-ID: <52A659F3.5030300@oracle.com> On 12/05/2013 10:23 AM, mark.reinhold at oracle.com wrote: > 2013/12/5 2:10 -0800, philip.race at oracle.com: >> I don't think what Artem said is quite correct. SQE may not do manual >> testing But the integrator certainly does. The final steps of our >> integration process has always included certain manual tests (applets, >> SwingSet, Java2Demo) on all the platforms (Windows, Linux, Solaris and >> now Mac) on the final built bits. We will need to maintain that >> process. > Lana -- Can you handle doing these manual tests once a week? Once we open up jdk9, I'll be doing integrations for multiple Jdk releases: - jdk7 update and sometimes there are two updates still being worked on at the same time, e.g. finishing 7u40 and starting 7u60, - jdk8 update (again could be two updates at the same time), - and jdk9. For all of my integrations I run these manual tests which is very tedious and time consuming job. It looks like we will need SQE help with doing the PITs. If they can perform the tests, then we could certainly do weekly integrations. One more point: Whenever a project becomes really active, things get rough. E.g. in the middle of Jdk8 development, we saw numerous build outages and various issues with incorrect fixes, etc. This is when people start appreciating isolated team forests. I understand the benefits of combining TL and Hotspot (we have seen many issues b/c of their code separation), however in my experience as the integrator, TL and Client do benefit from being isolated from each other. In the last year or so, there was just one case when a developer ask for a fix from Client to be brought over to TL earlier than scheduled, so they don't seem to suffer from being separate. However, there were multiple issues, when Awt or 2d or TL had their issues (broken builds or tests) and could work it out without affecting others and without any additional stress. Thanks, Lana From mark.reinhold at oracle.com Mon Dec 9 21:19:17 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 09 Dec 2013 21:19:17 -0800 Subject: Proposal to revise forest graph and integration practices for JDK 9 In-Reply-To: <52A659F3.5030300@oracle.com> References: <5290D912.7090002@oracle.com>, <20131205102333.258365@eggemoggin.niobe.net>, <52A659F3.5030300@oracle.com> Message-ID: <20131209211917.514157@eggemoggin.niobe.net> 2013/12/9 8:01 -0800, lana.steuck at oracle.com: > On 12/05/2013 10:23 AM, mark.reinhold at oracle.com wrote: >> Lana -- Can you handle doing these manual tests once a week? > > Once we open up jdk9, I'll be doing integrations for multiple Jdk releases: > - jdk7 update and sometimes there are two updates still being worked on > at the same time, e.g. finishing 7u40 and starting 7u60, > - jdk8 update (again could be two updates at the same time), > - and jdk9. > > For all of my integrations I run these manual tests which is very > tedious and time consuming job. It looks like we will need SQE help with > doing the PITs. If they can perform the tests, then we could certainly > do weekly integrations. Ultimately we want to do integrations even more frequently, so rather than count on SQE or other help we need to figure out how to automate these tests, or replace them with automated tests. > One more point: > Whenever a project becomes really active, things get rough. E.g. in the > middle of Jdk8 development, we saw numerous build outages and various > issues with incorrect fixes, etc. This is when people start appreciating > isolated team forests. I understand the benefits of combining TL and > Hotspot (we have seen many issues b/c of their code separation), however > in my experience as the integrator, TL and Client do benefit from being > isolated from each other. In the last year or so, there was just one > case when a developer ask for a fix from Client to be brought over to TL > earlier than scheduled, so they don't seem to suffer from being > separate. However, there were multiple issues, when Awt or 2d or TL had > their issues (broken builds or tests) and could work it out without > affecting others and without any additional stress. In general there seems to be more technical debt in the client areas than in core. We need to address that, and the sooner the better. In the meantime, however, let's create a separate JDK 9 client forest so that weekly dev -> master integrations aren't put at risk in case of instabilities in client code. - Mark From mark.reinhold at oracle.com Mon Dec 9 21:22:04 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 09 Dec 2013 21:22:04 -0800 Subject: Initial forests for JDK 9 Message-ID: <20131209212204.943183@eggemoggin.niobe.net> I'd like to go forward with Joe's proposal [1], as informed by our discussion over the last two weeks. My thanks to Joe for driving the conversation. To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: jdk9 "Master" forest -- a time-delayed, stable version of "dev" dev Default development forest -- replaces the current "tl" forest, integrates directly into the master client Client development forest (AWT, 2D, Swing) -- integrates into "dev" after suitable manual testing hotspot HotSpot development forest -- integrates into "dev" There will also be HotSpot group forests (hotspot-{comp,emb,gc,rt}), at least for now. We'll create these forests on Thursday as clones of the JDK 8 master forest, at tag jdk8-b120. I will, as suggested, fold active HSX and Nashorn contributors into the appropriate JDK 9 Project roles. To be specific: If you hold the Author, Committer, or Reviewer role in the JDK 8 Project [2], the HSX Project [3], the Nashorn Project [4], or some combination of these Projects, and you have contributed at least one changeset to JDK 8, either directly or indirectly, then in JDK 9 you will be granted the highest of the roles that you hold amongst those Projects. - Mark [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html [2] http://openjdk.java.net/census#jdk8 [3] http://openjdk.java.net/census#hsx [4] http://openjdk.java.net/census#nashorn From iris.clark at oracle.com Mon Dec 9 22:57:15 2013 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 9 Dec 2013 22:57:15 -0800 (PST) Subject: Initial forests for JDK 9 In-Reply-To: <20131209212204.943183@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> Message-ID: <91e8ed4c-4055-4533-aca1-dd5498916a1b@default> Hi. I'll be creating the JDK 9 forests on Thursday. I'm assuming that configuration should be the obvious extensions of what we have now for the JDK 8 Master and team forests (e.g. same jcheck settings, s/8/9/g ). One change I'd like to propose is modification of the destinations for push notifications. For JDK 8, changes to the Master and all team forests are sent to jdk8-changes at ojn. Push notifications to team forests are also sent to various -dev mailing lists. In some cases notifications may be sent to multiple mailing lists. For instance, changes to the tl forest are sent to compiler-dev, core-libs-dev, serviceability-dev, security-dev, and net-dev. With the reduction in the number of team repos in JDK 9 particularly for client, the number of duplicate push notifications will increase. I recommend that each of the forests send push notifications to new mailing lists which use the following naming convention: jdk9-forest?-changes at ojn . Notifications for jdk9 would be sent to jdk9-changes, dev to jdk9-dev-changes, hotspot-rt to jdk9-hotspot-rt-changes, etc. There are a couple of options for the set of initial subscribers: 1. All lists have an empty list of initial subscribers. We announce the existence of these lists and encourage people to subscribe as appropriate. 2. The set of initial subscribers for each list is initialized as the union of people currently subscribed to the -dev mailing lists that are used for JDK 8 notifications. For example, the initial subscribes of the jdk9-dev-changes would be the union of those e-mail addresses which receive mail from the {compiler,core-libs,serviceability,security,net}-dev lists. After the -changes lists have been created, anybody subscribing to a -dev list will need to consider whether they also wish to subscribe to a -changes list (i.e. automatic subscription to -changes will only occur only on creation). Thoughts? Thanks, iris -----Original Message----- From: Mark Reinhold Sent: Monday, December 09, 2013 9:22 PM To: jdk9-dev at openjdk.java.net Subject: Initial forests for JDK 9 I'd like to go forward with Joe's proposal [1], as informed by our discussion over the last two weeks. My thanks to Joe for driving the conversation. To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: jdk9 "Master" forest -- a time-delayed, stable version of "dev" dev Default development forest -- replaces the current "tl" forest, integrates directly into the master client Client development forest (AWT, 2D, Swing) -- integrates into "dev" after suitable manual testing hotspot HotSpot development forest -- integrates into "dev" There will also be HotSpot group forests (hotspot-{comp,emb,gc,rt}), at least for now. We'll create these forests on Thursday as clones of the JDK 8 master forest, at tag jdk8-b120. I will, as suggested, fold active HSX and Nashorn contributors into the appropriate JDK 9 Project roles. To be specific: If you hold the Author, Committer, or Reviewer role in the JDK 8 Project [2], the HSX Project [3], the Nashorn Project [4], or some combination of these Projects, and you have contributed at least one changeset to JDK 8, either directly or indirectly, then in JDK 9 you will be granted the highest of the roles that you hold amongst those Projects. - Mark [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html [2] http://openjdk.java.net/census#jdk8 [3] http://openjdk.java.net/census#hsx [4] http://openjdk.java.net/census#nashorn From magnus.ihse.bursie at oracle.com Tue Dec 10 01:20:04 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 10 Dec 2013 10:20:04 +0100 Subject: Initial forests for JDK 9 In-Reply-To: <91e8ed4c-4055-4533-aca1-dd5498916a1b@default> References: <20131209212204.943183@eggemoggin.niobe.net> <91e8ed4c-4055-4533-aca1-dd5498916a1b@default> Message-ID: <52A6DCC4.1080104@oracle.com> On 2013-12-10 07:57, Iris Clark wrote: > One change I'd like to propose is modification of the destinations for push notifications. > > For JDK 8, changes to the Master and all team forests are sent to jdk8-changes at ojn. Push notifications to team forests are also sent to various -dev mailing lists. In some cases notifications may be sent to multiple mailing lists. For instance, changes to the tl forest are sent to compiler-dev, core-libs-dev, serviceability-dev, security-dev, and net-dev. With the reduction in the number of team repos in JDK 9 particularly for client, the number of duplicate push notifications will increase. > > I recommend that each of the forests send push notifications to new mailing lists which use the following naming convention: jdk9-forest?-changes at ojn . Notifications for jdk9 would be sent to jdk9-changes, dev to jdk9-dev-changes, hotspot-rt to jdk9-hotspot-rt-changes, etc. Sounds very good to me! It's a constant struggle with less-capable mailing system to keep up reasonable filters to be able to separate hg notification from the proper discussions on the -dev mailing lists. > There are a couple of options for the set of initial subscribers: > > 1. All lists have an empty list of initial subscribers. We announce the existence of these lists and encourage people to subscribe as appropriate. > > 2. The set of initial subscribers for each list is initialized as the union of people currently subscribed to the -dev mailing lists that are used for JDK 8 notifications. For example, the initial subscribes of the jdk9-dev-changes would be the union of those e-mail addresses which receive mail from the {compiler,core-libs,serviceability,security,net}-dev lists. After the -changes lists have been created, anybody subscribing to a -dev list will need to consider whether they also wish to subscribe to a -changes list (i.e. automatic subscription to -changes will only occur only on creation). As long as you can subscribe/unsubscribe at will, I don't think the default is so important. Option 1 is the cleanest, but option 2 might provide "backward compatilibity" with current praxis. /Magnus From Alan.Bateman at oracle.com Tue Dec 10 05:08:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Dec 2013 13:08:20 +0000 Subject: Initial forests for JDK 9 In-Reply-To: <20131209212204.943183@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> Message-ID: <52A71244.7050106@oracle.com> On 10/12/2013 05:22, mark.reinhold at oracle.com wrote: > : > > We'll create these forests on Thursday as clones of the JDK 8 master > forest, at tag jdk8-b120. > I don't know if Steve Sides is on this mailing list but he recently submitted a number of bugs requesting that the copyright date be fixed up on files modified in 2013. I think there are several thousand files that need to be updated. I don't think it is critical to do before the jdk9 "split" but something to consider in case it would make live a bit easier to get this over with. It would require someone to run the update_copyright_year.sh script over all of the repositories and get it into master before b120 is tagged and maybe there isn't time for that. -Alan From John.Coomes at oracle.com Tue Dec 10 13:52:47 2013 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 10 Dec 2013 13:52:47 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131209212204.943183@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> Message-ID: <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: > I'd like to go forward with Joe's proposal [1], as informed by our > discussion over the last two weeks. My thanks to Joe for driving > the conversation. > > To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: > > jdk9 "Master" forest -- a time-delayed, stable version of "dev" > > dev Default development forest -- replaces the current "tl" > forest, integrates directly into the master > > client Client development forest (AWT, 2D, Swing) -- integrates > into "dev" after suitable manual testing > > hotspot HotSpot development forest -- integrates into "dev" Please name the above tree "hotspot-dev" instead of "hotspot", to avoid having a tree with the same name as a repo contained within it. During jdk7 development we used http://.../jdk7/hotspot/hotspot; it made conversations rather awkward and somtimes lead to confusion, since the term "hotspot" was ambiguous. > There will also be HotSpot group forests (hotspot-{comp,emb,gc,rt}), at > least for now. > > We'll create these forests on Thursday as clones of the JDK 8 master > forest, at tag jdk8-b120. > > I will, as suggested, fold active HSX and Nashorn contributors into the > appropriate JDK 9 Project roles. > > To be specific: If you hold the Author, Committer, or Reviewer role in > the JDK 8 Project [2], the HSX Project [3], the Nashorn Project [4], or > some combination of these Projects, and you have contributed at least one > changeset to JDK 8, either directly or indirectly, then in JDK 9 you will > be granted the highest of the roles that you hold amongst those Projects. There are a number of Contributors in hsx that are not yet Committers or Reviewers, but that are well along the way to earning those roles. I hope that changes already contributed to hsx will count toward achieving Committer and Reviewer status in jdk9. -John > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html > [2] http://openjdk.java.net/census#jdk8 > [3] http://openjdk.java.net/census#hsx > [4] http://openjdk.java.net/census#nashorn From joe.darcy at oracle.com Tue Dec 10 14:07:30 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 10 Dec 2013 14:07:30 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> References: <20131209212204.943183@eggemoggin.niobe.net> <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> Message-ID: <52A790A2.1040302@oracle.com> On 12/10/2013 01:52 PM, John Coomes wrote: > mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: >> I'd like to go forward with Joe's proposal [1], as informed by our >> discussion over the last two weeks. My thanks to Joe for driving >> the conversation. >> >> To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: >> >> jdk9 "Master" forest -- a time-delayed, stable version of "dev" >> >> dev Default development forest -- replaces the current "tl" >> forest, integrates directly into the master >> >> client Client development forest (AWT, 2D, Swing) -- integrates >> into "dev" after suitable manual testing >> >> hotspot HotSpot development forest -- integrates into "dev" > Please name the above tree "hotspot-dev" instead of "hotspot", to > avoid having a tree with the same name as a repo contained within it. > During jdk7 development we used http://.../jdk7/hotspot/hotspot; it > made conversations rather awkward and somtimes lead to confusion, > since the term "hotspot" was ambiguous. > If we are going to have "dev" and "hotspot-dev", should we also have "client-dev" for consistency? -Joe From joe.darcy at oracle.com Tue Dec 10 14:09:59 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 10 Dec 2013 14:09:59 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <91e8ed4c-4055-4533-aca1-dd5498916a1b@default> References: <20131209212204.943183@eggemoggin.niobe.net> <91e8ed4c-4055-4533-aca1-dd5498916a1b@default> Message-ID: <52A79137.7080507@oracle.com> On 12/09/2013 10:57 PM, Iris Clark wrote: > Hi. > > I'll be creating the JDK 9 forests on Thursday. I'm assuming that configuration should be the obvious extensions of what we have now for the JDK 8 Master and team forests (e.g. same jcheck settings, s/8/9/g ). > > One change I'd like to propose is modification of the destinations for push notifications. > > For JDK 8, changes to the Master and all team forests are sent to jdk8-changes at ojn. Push notifications to team forests are also sent to various -dev mailing lists. In some cases notifications may be sent to multiple mailing lists. For instance, changes to the tl forest are sent to compiler-dev, core-libs-dev, serviceability-dev, security-dev, and net-dev. With the reduction in the number of team repos in JDK 9 particularly for client, the number of duplicate push notifications will increase. > > I recommend that each of the forests send push notifications to new mailing lists which use the following naming convention: jdk9-forest?-changes at ojn . Notifications for jdk9 would be sent to jdk9-changes, dev to jdk9-dev-changes, hotspot-rt to jdk9-hotspot-rt-changes, etc. That sounds like a good change to me; I think using option 1) for opt-in would be fine. -Joe From mark.reinhold at oracle.com Tue Dec 10 14:13:04 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 10 Dec 2013 14:13:04 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52A790A2.1040302@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com>, <52A790A2.1040302@oracle.com> Message-ID: <20131210141304.717243@eggemoggin.niobe.net> 2013/12/10 6:07 -0800, joe.darcy at oracle.com: > On 12/10/2013 01:52 PM, John Coomes wrote: >> Please name the above tree "hotspot-dev" instead of "hotspot", to >> avoid having a tree with the same name as a repo contained within it. >> During jdk7 development we used http://.../jdk7/hotspot/hotspot; it >> made conversations rather awkward and somtimes lead to confusion, >> since the term "hotspot" was ambiguous. > > If we are going to have "dev" and "hotspot-dev", should we also have > "client-dev" for consistency? Oooh, a bikeshed! Adding "-dev" suffixes everywhere is just redundant. If the hotspot forests need a prefix other than "hotspot", how about just "hs"? - Mark From volker.simonis at gmail.com Tue Dec 10 14:16:39 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Dec 2013 23:16:39 +0100 Subject: Initial forests for JDK 9 In-Reply-To: <20131209212204.943183@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> Message-ID: Hi Mark, why don't we create something like http://hg.openjdk.java.net/dev with master, dev, client and hotspot forest beneath it. These forests could live "forever". Any time a new release is ready, we would then clone jdk9, jdk10, etc from dev/master. Wouldn't that be a more natural setup? Regards, Volker On Tuesday, December 10, 2013, wrote: > I'd like to go forward with Joe's proposal [1], as informed by our > discussion over the last two weeks. My thanks to Joe for driving > the conversation. > > To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: > > jdk9 "Master" forest -- a time-delayed, stable version of "dev" > > dev Default development forest -- replaces the current "tl" > forest, integrates directly into the master > > client Client development forest (AWT, 2D, Swing) -- integrates > into "dev" after suitable manual testing > > hotspot HotSpot development forest -- integrates into "dev" > > There will also be HotSpot group forests (hotspot-{comp,emb,gc,rt}), at > least for now. > > We'll create these forests on Thursday as clones of the JDK 8 master > forest, at tag jdk8-b120. > > I will, as suggested, fold active HSX and Nashorn contributors into the > appropriate JDK 9 Project roles. > > To be specific: If you hold the Author, Committer, or Reviewer role in > the JDK 8 Project [2], the HSX Project [3], the Nashorn Project [4], or > some combination of these Projects, and you have contributed at least one > changeset to JDK 8, either directly or indirectly, then in JDK 9 you will > be granted the highest of the roles that you hold amongst those Projects. > > - Mark > > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html > [2] http://openjdk.java.net/census#jdk8 > [3] http://openjdk.java.net/census#hsx > [4] http://openjdk.java.net/census#nashorn > From volker.simonis at gmail.com Tue Dec 10 14:18:45 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Dec 2013 23:18:45 +0100 Subject: Initial forests for JDK 9 In-Reply-To: <20131209212204.943183@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> Message-ID: Hi Mark, why don't we create something like http://hg.openjdk.java.net/dev with master, dev, client and hotspot forest beneath it. These forests could live "forever". Any time a new release is ready, we would th On Tuesday, December 10, 2013, wrote: > I'd like to go forward with Joe's proposal [1], as informed by our > discussion over the last two weeks. My thanks to Joe for driving > the conversation. > > To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: > > jdk9 "Master" forest -- a time-delayed, stable version of "dev" > > dev Default development forest -- replaces the current "tl" > forest, integrates directly into the master > > client Client development forest (AWT, 2D, Swing) -- integrates > into "dev" after suitable manual testing > > hotspot HotSpot development forest -- integrates into "dev" > > There will also be HotSpot group forests (hotspot-{comp,emb,gc,rt}), at > least for now. > > We'll create these forests on Thursday as clones of the JDK 8 master > forest, at tag jdk8-b120. > > I will, as suggested, fold active HSX and Nashorn contributors into the > appropriate JDK 9 Project roles. > > To be specific: If you hold the Author, Committer, or Reviewer role in > the JDK 8 Project [2], the HSX Project [3], the Nashorn Project [4], or > some combination of these Projects, and you have contributed at least one > changeset to JDK 8, either directly or indirectly, then in JDK 9 you will > be granted the highest of the roles that you hold amongst those Projects. > > - Mark > > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html > [2] http://openjdk.java.net/census#jdk8 > [3] http://openjdk.java.net/census#hsx > [4] http://openjdk.java.net/census#nashorn > From neugens.limasoftware at gmail.com Tue Dec 10 14:37:50 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 10 Dec 2013 23:37:50 +0100 Subject: Initial forests for JDK 9 In-Reply-To: References: <20131209212204.943183@eggemoggin.niobe.net> Message-ID: Sounds more reasonable (and natural!) to me too. Cheers, Mario Il 10/dic/2013 23:17 "Volker Simonis" ha scritto: > Hi Mark, > > why don't we create something like http://hg.openjdk.java.net/dev with > master, dev, client and hotspot forest beneath it. These forests could live > "forever". Any time a new release is ready, we would then clone jdk9, > jdk10, etc from dev/master. Wouldn't that be a more natural setup? > > Regards, > Volker > > On Tuesday, December 10, 2013, wrote: > > > I'd like to go forward with Joe's proposal [1], as informed by our > > discussion over the last two weeks. My thanks to Joe for driving > > the conversation. > > > > To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: > > > > jdk9 "Master" forest -- a time-delayed, stable version of "dev" > > > > dev Default development forest -- replaces the current "tl" > > forest, integrates directly into the master > > > > client Client development forest (AWT, 2D, Swing) -- integrates > > into "dev" after suitable manual testing > > > > hotspot HotSpot development forest -- integrates into "dev" > > > > There will also be HotSpot group forests (hotspot-{comp,emb,gc,rt}), at > > least for now. > > > > We'll create these forests on Thursday as clones of the JDK 8 master > > forest, at tag jdk8-b120. > > > > I will, as suggested, fold active HSX and Nashorn contributors into the > > appropriate JDK 9 Project roles. > > > > To be specific: If you hold the Author, Committer, or Reviewer role in > > the JDK 8 Project [2], the HSX Project [3], the Nashorn Project [4], or > > some combination of these Projects, and you have contributed at least one > > changeset to JDK 8, either directly or indirectly, then in JDK 9 you will > > be granted the highest of the roles that you hold amongst those Projects. > > > > - Mark > > > > > > [1] > > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html > > [2] http://openjdk.java.net/census#jdk8 > > [3] http://openjdk.java.net/census#hsx > > [4] http://openjdk.java.net/census#nashorn > > > From neugens.limasoftware at gmail.com Tue Dec 10 15:02:19 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 11 Dec 2013 00:02:19 +0100 Subject: Initial forests for JDK 9 In-Reply-To: <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> References: <20131209212204.943183@eggemoggin.niobe.net> <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> Message-ID: Il 10/dic/2013 22:53 "John Coomes" ha scritto: > > mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: > > I'd like to go forward with Joe's proposal [1], as informed by our > > discussion over the last two weeks. My thanks to Joe for driving > > the conversation. > > > > To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: > > > > jdk9 "Master" forest -- a time-delayed, stable version of "dev" > > > > dev Default development forest -- replaces the current "tl" > > forest, integrates directly into the master > > > > client Client development forest (AWT, 2D, Swing) -- integrates > > into "dev" after suitable manual testing > > > > hotspot HotSpot development forest -- integrates into "dev" > > Please name the above tree "hotspot-dev" instead of "hotspot", to > avoid having a tree with the same name as a repo contained within it. > During jdk7 development we used http://.../jdk7/hotspot/hotspot; it > made conversations rather awkward and somtimes lead to confusion, > since the term "hotspot" was ambiguous. > > > There will also be HotSpot group forests (hotspot-{comp,emb,gc,rt}), at > > least for now. > > > > We'll create these forests on Thursday as clones of the JDK 8 master > > forest, at tag jdk8-b120. > > > > I will, as suggested, fold active HSX and Nashorn contributors into the > > appropriate JDK 9 Project roles. > > > > To be specific: If you hold the Author, Committer, or Reviewer role in > > the JDK 8 Project [2], the HSX Project [3], the Nashorn Project [4], or > > some combination of these Projects, and you have contributed at least one > > changeset to JDK 8, either directly or indirectly, then in JDK 9 you will > > be granted the highest of the roles that you hold amongst those Projects. > > There are a number of Contributors in hsx that are not yet Committers > or Reviewers, but that are well along the way to earning those roles. > I hope that changes already contributed to hsx will count toward > achieving Committer and Reviewer status in jdk9. History gets carried over, so this shouldn't be a problem, otherwise we would all be resetted at every major update. I think the bylaws is pretty clear that experiences toward roles can be carried over, since is not stated otherwise: "An OpenJDK Member is a Contributor who has demonstrated a history of significant contributions to the Community as recognized by a vote of the existing OpenJDK Members". "A Committer to a Project is an Author who has been granted direct push access to the Project?s code repositories". "A Reviewer for a Project is an experienced Committer who has the authority to approve changesets destined for code repositories designated by the Project Lead as requiring formal change review". In other words, is up to a committer/member/lead/Oracle to propose a new committer/member/lead, but it's not stated regarding the specific of the merits, which are instead a common sense definition based on the whole history of collaboration. Cheers, Mario From John.Coomes at oracle.com Wed Dec 11 15:39:47 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 11 Dec 2013 15:39:47 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131210141304.717243@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> <52A790A2.1040302@oracle.com> <20131210141304.717243@eggemoggin.niobe.net> Message-ID: <21160.63427.741873.686171@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: > 2013/12/10 6:07 -0800, joe.darcy at oracle.com: > > On 12/10/2013 01:52 PM, John Coomes wrote: > >> Please name the above tree "hotspot-dev" instead of "hotspot", to > >> avoid having a tree with the same name as a repo contained within it. > >> During jdk7 development we used http://.../jdk7/hotspot/hotspot; it > >> made conversations rather awkward and somtimes lead to confusion, > >> since the term "hotspot" was ambiguous. > > > > If we are going to have "dev" and "hotspot-dev", should we also have > > "client-dev" for consistency? > > Oooh, a bikeshed! > > Adding "-dev" suffixes everywhere is just redundant. > > If the hotspot forests need a prefix other than "hotspot", > how about just "hs"? Avoiding hotspot/hotspot in the path is the main concern. Whether we use "hs" or "hotspot-dev" or "hotspot-main" to do that doesn't matter much. -John From stuart.marks at oracle.com Wed Dec 11 18:53:14 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 11 Dec 2013 18:53:14 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <21160.63427.741873.686171@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> References: <20131209212204.943183@eggemoggin.niobe.net> <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> <52A790A2.1040302@oracle.com> <20131210141304.717243@eggemoggin.niobe.net> <21160.63427.741873.686171@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> Message-ID: <52A9251A.7030808@oracle.com> On 12/11/13 3:39 PM, John Coomes wrote: > mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: >> Oooh, a bikeshed! >> >> Adding "-dev" suffixes everywhere is just redundant. >> >> If the hotspot forests need a prefix other than "hotspot", >> how about just "hs"? > > Avoiding hotspot/hotspot in the path is the main concern. Whether we > use "hs" or "hotspot-dev" or "hotspot-main" to do that doesn't matter > much. As long as we're bikeshedding...er, no seriously. I agree that having hotspot/hotspot in the path is a concern and should be avoided. By the same token, what should the master forest be called? Mark's original proposal said: > To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: > > jdk9 "Master" forest -- a time-delayed, stable version of "dev" This puts jdk9/jdk9 in the path. Since everybody describes this as the "master" forest, why don't we actually call it "master"? Hence the forests under jdk9 would be master, dev, client, and the hs hierarchy (or whatever it ends up being called). s'marks From stuart.marks at oracle.com Wed Dec 11 18:57:24 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 11 Dec 2013 18:57:24 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <91e8ed4c-4055-4533-aca1-dd5498916a1b@default> References: <20131209212204.943183@eggemoggin.niobe.net> <91e8ed4c-4055-4533-aca1-dd5498916a1b@default> Message-ID: <52A92614.40901@oracle.com> On 12/9/13 10:57 PM, Iris Clark wrote: > For JDK 8, changes to the Master and all team forests are sent to jdk8-changes at ojn. Push notifications to team forests are also sent to various -dev mailing lists. In some cases notifications may be sent to multiple mailing lists. For instance, changes to the tl forest are sent to compiler-dev, core-libs-dev, serviceability-dev, security-dev, and net-dev. With the reduction in the number of team repos in JDK 9 particularly for client, the number of duplicate push notifications will increase. > > I recommend that each of the forests send push notifications to new mailing lists which use the following naming convention: jdk9-forest?-changes at ojn . Notifications for jdk9 would be sent to jdk9-changes, dev to jdk9-dev-changes, hotspot-rt to jdk9-hotspot-rt-changes, etc. I wholeheartedly agree that push notifications should be moved away from the various *-dev discussion lists and moved onto dedicated change notification lists, per forest. If the "master" forest ends up actually being called "master" per my earlier e-mail then the notification list for it would be jdk9-master-changes. s'marks From mark.reinhold at oracle.com Thu Dec 12 07:32:23 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Dec 2013 07:32:23 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52A9251A.7030808@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <21159.36143.953577.97259@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com>, <52A790A2.1040302@oracle.com>, <20131210141304.717243@eggemoggin.niobe.net>, <21160.63427.741873.686171@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com>, <52A9251A.7030808@oracle.com> Message-ID: <20131212073223.970018@eggemoggin.niobe.net> 2013/12/11 10:53 -0800, stuart.marks at oracle.com: > As long as we're bikeshedding...er, no seriously. I agree that having > hotspot/hotspot in the path is a concern and should be avoided. By the same > token, what should the master forest be called? Mark's original proposal said: > >> To summarize, under http://hg.openjdk.java.net/jdk9 we'll have: >> >> jdk9 "Master" forest -- a time-delayed, stable version of "dev" > > This puts jdk9/jdk9 in the path. Since everybody describes this as the "master" > forest, why don't we actually call it "master"? Hence the forests under jdk9 > would be master, dev, client, and the hs hierarchy (or whatever it ends up being > called). Tempting, but I think it's a different situation. If you clone the JDK 9 master then, by default, you get a forest named "jdk9", with "hotspot", "jdk", "nashorn", and other repos inside. There's no conflict in a local forest. If you clone the main HotSpot forest then, by default, you get a forest named "hotspot", with "hotspot", "jdk", etc., inside. The duplication of "hotspot" in the local forest is confusing -- if you say "hotspot" do you mean the forest, or the hotspot/hotspot repo? So we'll rename the forest "hs" to fix that. - Mark From mark.reinhold at oracle.com Thu Dec 12 07:35:44 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Dec 2013 07:35:44 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52A92614.40901@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <91e8ed4c-4055-4533-aca1-dd5498916a1b@default>, <52A92614.40901@oracle.com> Message-ID: <20131212073544.949238@eggemoggin.niobe.net> 2013/12/11 10:57 -0800, stuart.marks at oracle.com: > I wholeheartedly agree that push notifications should be moved away from the > various *-dev discussion lists and moved onto dedicated change notification > lists, per forest. > > If the "master" forest ends up actually being called "master" per my earlier > e-mail then the notification list for it would be jdk9-master-changes. I think the master forest is the exception. Everyone working on the release should be aware of changes to the master, so notifications for that forest should go to jdk9-dev, just as notifications for the JDK 8 master went to jdk8-dev. - Mark From stuart.marks at oracle.com Thu Dec 12 10:12:08 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 12 Dec 2013 10:12:08 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131212073544.949238@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net>, <91e8ed4c-4055-4533-aca1-dd5498916a1b@default>, <52A92614.40901@oracle.com> <20131212073544.949238@eggemoggin.niobe.net> Message-ID: <52A9FC78.3060207@oracle.com> On 12/12/13 7:35 AM, mark.reinhold at oracle.com wrote: > 2013/12/11 10:57 -0800, stuart.marks at oracle.com: >> I wholeheartedly agree that push notifications should be moved away from the >> various *-dev discussion lists and moved onto dedicated change notification >> lists, per forest. >> >> If the "master" forest ends up actually being called "master" per my earlier >> e-mail then the notification list for it would be jdk9-master-changes. > > I think the master forest is the exception. Everyone working on the > release should be aware of changes to the master, so notifications > for that forest should go to jdk9-dev, just as notifications for the > JDK 8 master went to jdk8-dev. I agree that everybody **should** be aware of changes to the master, but mixing changeset notifications and discussion makes it more difficult for people to control how they process mail. For example, I do a lot of filtering of OpenJDK mail based on the mailing list to which it was delivered (using the Delivered-To header). If notifications were mixed with discussion, I'd have to apply an additional filter based on the subject line. This fails with replies to changeset notices, for example. Speaking of replies, should notifications set a reply-to header directing replies to a discussion list? Having discussion on a dedicated notification list would seem like a problem. (This applies to all the per-forest notification lists, not just master.) s'marks From mark.reinhold at oracle.com Thu Dec 12 11:13:29 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Dec 2013 11:13:29 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52A9FC78.3060207@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212073544.949238@eggemoggin.niobe.net>, <52A9FC78.3060207@oracle.com> Message-ID: <20131212111329.371571@eggemoggin.niobe.net> 2013/12/12 2:12 -0800, stuart.marks at oracle.com: > I agree that everybody **should** be aware of changes to the master, but mixing > changeset notifications and discussion makes it more difficult for people to > control how they process mail. For example, I do a lot of filtering of OpenJDK > mail based on the mailing list to which it was delivered (using the Delivered-To > header). If notifications were mixed with discussion, I'd have to apply an > additional filter based on the subject line. This fails with replies to > changeset notices, for example. Filtering out changeset notifications is easy -- just look for the X-Hg-URL (or X-Hg-Changeset) header. > Speaking of replies, should notifications set a reply-to header directing > replies to a discussion list? Having discussion on a dedicated notification list > would seem like a problem. (This applies to all the per-forest notification > lists, not just master.) Iris -- What's your plan for the Reply-To headers of changeset notifications? - Mark From iris.clark at oracle.com Thu Dec 12 12:20:39 2013 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 12 Dec 2013 12:20:39 -0800 (PST) Subject: Initial forests for JDK 9 In-Reply-To: <20131212111329.371571@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> Message-ID: Hi, Mark. >> Speaking of replies, should notifications set a reply-to header >> directing replies to a discussion list? Having discussion on a >> dedicated notification list would seem like a problem. (This applies >> to all the per-forest notification lists, not just master.) > Iris -- What's your plan for the Reply-To headers of changeset notifications? Based on where the notifications for jdk8 go, these are the default "Reply-to" values for each of the new mailing lists: jdk9-changes: jdk9-dev jdk9-dev-changes: compiler-dev, core-libs-dev, serviceability-dev, net-dev, build-dev jdk9-client-changes: 2d-dev, awt-dev, swing-dev jdk9-hs-changes: hotspot-dev jdk9-hs-comp-changes: hotspot-compiler-dev jdk9-hs-emb-changes: hotspot-runtime-dev jdk9-hs-gc-changes: hotspot-gc-dev jdk9-hs-rt-changes: hotspot-runtime-dev, serviceability-dev Does everything look right? Thanks, iris From daniel.daugherty at oracle.com Thu Dec 12 12:56:51 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Dec 2013 13:56:51 -0700 Subject: Initial forests for JDK 9 In-Reply-To: References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> Message-ID: <52AA2313.3040903@oracle.com> On 12/12/13 1:20 PM, Iris Clark wrote: > Hi, Mark. > >>> Speaking of replies, should notifications set a reply-to header >>> directing replies to a discussion list? Having discussion on a >>> dedicated notification list would seem like a problem. (This applies >>> to all the per-forest notification lists, not just master.) >> Iris -- What's your plan for the Reply-To headers of changeset notifications? > Based on where the notifications for jdk8 go, these are the default "Reply-to" values for each of the new mailing lists: > > jdk9-changes: jdk9-dev > jdk9-dev-changes: compiler-dev, core-libs-dev, serviceability-dev, net-dev, build-dev > jdk9-client-changes: 2d-dev, awt-dev, swing-dev > jdk9-hs-changes: hotspot-dev > jdk9-hs-comp-changes: hotspot-compiler-dev > jdk9-hs-emb-changes: hotspot-runtime-dev There should be an Embedded team alias in addition to hotspot-runtime-dev for this one.Yes, Runtime wants to know about the Embedded team's work, but I think the Embedded team would also like to know... :-) Dan > jdk9-hs-gc-changes: hotspot-gc-dev > jdk9-hs-rt-changes: hotspot-runtime-dev, serviceability-dev > > Does everything look right? > > Thanks, > iris From iris.clark at oracle.com Thu Dec 12 13:07:30 2013 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 12 Dec 2013 13:07:30 -0800 (PST) Subject: Initial forests for JDK 9 In-Reply-To: <52AA2313.3040903@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> <52AA2313.3040903@oracle.com> Message-ID: <49c0385e-da85-4036-979f-5b41ee9ddc8f@default> >> jdk9-hs-emb-changes: hotspot-runtime-dev > There should be an Embedded team alias in addition to hotspot-runtime-dev for this one.Yes, Runtime wants to know about the Embedded team's work, but I think the Embedded team would also like to know... :-) Sounds reasonable. Which openjdk mailing list do they use: http://mail.openjdk.java.net/mailman/listinfo Thanks, iris -----Original Message----- From: Daniel D. Daugherty Sent: Thursday, December 12, 2013 12:57 PM To: Iris Clark Cc: Mark Reinhold; Stuart Marks; jdk9-dev at openjdk.java.net Subject: Re: Initial forests for JDK 9 On 12/12/13 1:20 PM, Iris Clark wrote: > Hi, Mark. > >>> Speaking of replies, should notifications set a reply-to header >>> directing replies to a discussion list? Having discussion on a >>> dedicated notification list would seem like a problem. (This applies >>> to all the per-forest notification lists, not just master.) >> Iris -- What's your plan for the Reply-To headers of changeset notifications? > Based on where the notifications for jdk8 go, these are the default "Reply-to" values for each of the new mailing lists: > > jdk9-changes: jdk9-dev > jdk9-dev-changes: compiler-dev, core-libs-dev, serviceability-dev, net-dev, build-dev > jdk9-client-changes: 2d-dev, awt-dev, swing-dev > jdk9-hs-changes: hotspot-dev > jdk9-hs-comp-changes: hotspot-compiler-dev > jdk9-hs-emb-changes: hotspot-runtime-dev There should be an Embedded team alias in addition to hotspot-runtime-dev for this one.Yes, Runtime wants to know about the Embedded team's work, but I think the Embedded team would also like to know... :-) Dan > jdk9-hs-gc-changes: hotspot-gc-dev > jdk9-hs-rt-changes: hotspot-runtime-dev, serviceability-dev > > Does everything look right? > > Thanks, > iris From daniel.daugherty at oracle.com Thu Dec 12 13:17:32 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Dec 2013 14:17:32 -0700 Subject: Initial forests for JDK 9 In-Reply-To: <49c0385e-da85-4036-979f-5b41ee9ddc8f@default> References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> <52AA2313.3040903@oracle.com> <49c0385e-da85-4036-979f-5b41ee9ddc8f@default> Message-ID: <52AA27EC.2040708@oracle.com> On 12/12/13 2:07 PM, Iris Clark wrote: >>> jdk9-hs-emb-changes: hotspot-runtime-dev >> There should be an Embedded team alias in addition to hotspot-runtime-dev for this one.Yes, Runtime wants to know about the Embedded team's work, but I think the Embedded team would also like to know... :-) > Sounds reasonable. Which openjdk mailing list do they use: > > http://mail.openjdk.java.net/mailman/listinfo Oh.... Good question... Adding Gary Collins to this thread... Dan > > Thanks, > iris > > -----Original Message----- > From: Daniel D. Daugherty > Sent: Thursday, December 12, 2013 12:57 PM > To: Iris Clark > Cc: Mark Reinhold; Stuart Marks; jdk9-dev at openjdk.java.net > Subject: Re: Initial forests for JDK 9 > > On 12/12/13 1:20 PM, Iris Clark wrote: >> Hi, Mark. >> >>>> Speaking of replies, should notifications set a reply-to header >>>> directing replies to a discussion list? Having discussion on a >>>> dedicated notification list would seem like a problem. (This applies >>>> to all the per-forest notification lists, not just master.) >>> Iris -- What's your plan for the Reply-To headers of changeset notifications? >> Based on where the notifications for jdk8 go, these are the default "Reply-to" values for each of the new mailing lists: >> >> jdk9-changes: jdk9-dev >> jdk9-dev-changes: compiler-dev, core-libs-dev, serviceability-dev, net-dev, build-dev >> jdk9-client-changes: 2d-dev, awt-dev, swing-dev >> jdk9-hs-changes: hotspot-dev >> jdk9-hs-comp-changes: hotspot-compiler-dev >> jdk9-hs-emb-changes: hotspot-runtime-dev > There should be an Embedded team alias in addition to hotspot-runtime-dev for this one.Yes, Runtime wants to know about the Embedded team's work, but I think the Embedded team would also like to know... :-) > > Dan > > >> jdk9-hs-gc-changes: hotspot-gc-dev >> jdk9-hs-rt-changes: hotspot-runtime-dev, serviceability-dev >> >> Does everything look right? >> >> Thanks, >> iris From iris.clark at oracle.com Thu Dec 12 13:18:11 2013 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 12 Dec 2013 13:18:11 -0800 (PST) Subject: Initial forests for JDK 9 In-Reply-To: <52AA27EC.2040708@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> <52AA2313.3040903@oracle.com> <49c0385e-da85-4036-979f-5b41ee9ddc8f@default> <52AA27EC.2040708@oracle.com> Message-ID: <42b71cbb-0395-466f-9436-f65ec7ca9c54@default> >>>> jdk9-hs-emb-changes: hotspot-runtime-dev >>> There should be an Embedded team alias in addition to >>> hotspot-runtime-dev for this one.Yes, Runtime wants to know about the >>> Embedded team's work, but I think the Embedded team would also like >>> to know... :-) >> Sounds reasonable. Which openjdk mailing list do they use: >> >> http://mail.openjdk.java.net/mailman/listinfo > Oh.... Good question... Adding Gary Collins to this thread... Right now, hsx/hotspot-emb on hg.openjdk goes to hotspot-runtime-dev only. iris From stuart.marks at oracle.com Thu Dec 12 14:54:52 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 12 Dec 2013 14:54:52 -0800 Subject: Initial forests for JDK 9 In-Reply-To: References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> Message-ID: <52AA3EBC.70608@oracle.com> On 12/12/13 12:20 PM, Iris Clark wrote: > Based on where the notifications for jdk8 go, these are the default "Reply-to" values for each of the new mailing lists: > > jdk9-changes: jdk9-dev > jdk9-dev-changes: compiler-dev, core-libs-dev, serviceability-dev, net-dev, build-dev > jdk9-client-changes: 2d-dev, awt-dev, swing-dev > jdk9-hs-changes: hotspot-dev > jdk9-hs-comp-changes: hotspot-compiler-dev > jdk9-hs-emb-changes: hotspot-runtime-dev > jdk9-hs-gc-changes: hotspot-gc-dev > jdk9-hs-rt-changes: hotspot-runtime-dev, serviceability-dev Seems sensible to me, modulo resolution of the embedded notification issue being discussed on the rest of this thread. Now wait... is there a jdk9-changes list that will receive change notifications for the jdk9 master forest? Because Mark had said earlier, > I think the master forest is the exception. Everyone working on the > release should be aware of changes to the master, so notifications > for that forest should go to jdk9-dev, just as notifications for the > JDK 8 master went to jdk8-dev. According to that, there would be no jdk9-changes list, and change notifications for master would go directly to jdk9-dev. (And presumably replies as well.) I don't particularly care whether the notification list for changes to master is called jdk9-changes or jdk9-master changes. I'd like for there to be one separate from the jdk9-dev discussion list. In my opinion, mixing in the change notifications just clutters up the discussion list. s'marks From joe.darcy at oracle.com Thu Dec 12 15:09:06 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 12 Dec 2013 15:09:06 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52AA3EBC.70608@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> <52AA3EBC.70608@oracle.com> Message-ID: <52AA4212.30603@oracle.com> On 12/12/2013 2:54 PM, Stuart Marks wrote: > On 12/12/13 12:20 PM, Iris Clark wrote: >> Based on where the notifications for jdk8 go, these are the default >> "Reply-to" values for each of the new mailing lists: >> >> jdk9-changes: jdk9-dev >> jdk9-dev-changes: compiler-dev, core-libs-dev, serviceability-dev, >> net-dev, build-dev >> jdk9-client-changes: 2d-dev, awt-dev, swing-dev >> jdk9-hs-changes: hotspot-dev >> jdk9-hs-comp-changes: hotspot-compiler-dev >> jdk9-hs-emb-changes: hotspot-runtime-dev >> jdk9-hs-gc-changes: hotspot-gc-dev >> jdk9-hs-rt-changes: hotspot-runtime-dev, serviceability-dev > > Seems sensible to me, modulo resolution of the embedded notification > issue being discussed on the rest of this thread. > > Now wait... is there a jdk9-changes list that will receive change > notifications for the jdk9 master forest? Because Mark had said earlier, > >> I think the master forest is the exception. Everyone working on the >> release should be aware of changes to the master, so notifications >> for that forest should go to jdk9-dev, just as notifications for the >> JDK 8 master went to jdk8-dev. > > According to that, there would be no jdk9-changes list, and change > notifications for master would go directly to jdk9-dev. (And > presumably replies as well.) > > I don't particularly care whether the notification list for changes to > master is called jdk9-changes or jdk9-master changes. I'd like for > there to be one separate from the jdk9-dev discussion list. In my > opinion, mixing in the change notifications just clutters up the > discussion list. > > FWIW, I would also prefer if the jdk9-dev list were only for discussions and for all push notifications to go to a separate list. However, it may be helpful to have a coarser grained notification like "an integration has occurred" notice being sent to the dev list. -Joe From sean.mullan at oracle.com Thu Dec 12 15:18:12 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Dec 2013 18:18:12 -0500 Subject: Initial forests for JDK 9 In-Reply-To: References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> Message-ID: <52AA4434.5040706@oracle.com> On 12/12/13, 3:20 PM, Iris Clark wrote: > jdk9-dev-changes: compiler-dev, core-libs-dev, serviceability-dev, net-dev, build-dev and security-dev --Sean From jonathan.gibbons at oracle.com Thu Dec 12 15:27:16 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Dec 2013 15:27:16 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131212073544.949238@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net>, <91e8ed4c-4055-4533-aca1-dd5498916a1b@default>, <52A92614.40901@oracle.com> <20131212073544.949238@eggemoggin.niobe.net> Message-ID: <52AA4654.6040709@oracle.com> On 12/12/2013 07:35 AM, mark.reinhold at oracle.com wrote: > 2013/12/11 10:57 -0800, stuart.marks at oracle.com: >> I wholeheartedly agree that push notifications should be moved away from the >> various *-dev discussion lists and moved onto dedicated change notification >> lists, per forest. >> >> If the "master" forest ends up actually being called "master" per my earlier >> e-mail then the notification list for it would be jdk9-master-changes. > I think the master forest is the exception. Everyone working on the > release should be aware of changes to the master, so notifications > for that forest should go to jdk9-dev, just as notifications for the > JDK 8 master went to jdk8-dev. > > - Mark I question why most folk working on the release should be aware of what is going on in the master. Most folk working on the release will be integrating up through the dev forest, so that is the forest that folk should be concerned about. If in this new world the master is just going to be a time-delayed, better tested, cache of the dev forest, then most folk will already be aware of the changes that have gone in. Rather than sending messages to jdk9-dev, how about setting up jdk9-changes as a new alias, initially populated with the contents of the jdk9-dev alias, but allowing people to opt-in or opt-out of those messages as they choose, rather than always sending potentially unwanted messages such that they then have to go to the trouble of filtering out. -- Jon From mark.reinhold at oracle.com Thu Dec 12 16:02:46 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Dec 2013 16:02:46 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52AA4654.6040709@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212073544.949238@eggemoggin.niobe.net>, <52AA4654.6040709@oracle.com> Message-ID: <20131212160246.760129@eggemoggin.niobe.net> 2013/12/12 7:27 -0800, jonathan.gibbons at oracle.com: > On 12/12/2013 07:35 AM, mark.reinhold at oracle.com wrote: >> I think the master forest is the exception. Everyone working on the >> release should be aware of changes to the master, so notifications >> for that forest should go to jdk9-dev, just as notifications for the >> JDK 8 master went to jdk8-dev. > > I question why most folk working on the release should be aware of > what is going on in the master. Most folk working on the release will > be integrating up through the dev forest, so that is the forest that > folk should be concerned about. If in this new world the master is just > going to be a time-delayed, better tested, cache of the dev forest, then > most folk will already be aware of the changes that have gone in. Hmm. Fair point. This is a new world -- or at least we're trying to make it so. > Rather than sending messages to jdk9-dev, how about setting up > jdk9-changes as a new alias, initially populated with the contents of > the jdk9-dev alias, but allowing people to opt-in or opt-out of those > messages as they choose, rather than always sending potentially unwanted > messages such that they then have to go to the trouble of filtering out. Okay. How about we modify Iris's original proposal as follows: jdk9-changes Changes to the JDK 9 master forest jdk9-all-changes Changes to all JDK 9 forests (including master) Change notifications for the master will only go to these two lists, and specifically not to jdk9-dev. To keep things simple, all of these lists will be opt-in. Comments? - Mark From John.Coomes at oracle.com Thu Dec 12 17:53:26 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 12 Dec 2013 17:53:26 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131212160246.760129@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> <20131212073544.949238@eggemoggin.niobe.net> <52AA4654.6040709@oracle.com> <20131212160246.760129@eggemoggin.niobe.net> Message-ID: <21162.26774.42451.518958@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: > 2013/12/12 7:27 -0800, jonathan.gibbons at oracle.com: > > On 12/12/2013 07:35 AM, mark.reinhold at oracle.com wrote: > ... > Okay. How about we modify Iris's original proposal as follows: > > jdk9-changes Changes to the JDK 9 master forest > jdk9-all-changes Changes to all JDK 9 forests (including master) > > Change notifications for the master will only go to these two lists, > and specifically not to jdk9-dev. > > To keep things simple, all of these lists will be opt-in. > > Comments? Much better. -John From mikael.auno at oracle.com Fri Dec 13 01:56:18 2013 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 13 Dec 2013 10:56:18 +0100 Subject: Initial forests for JDK 9 In-Reply-To: <20131212111329.371571@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212073544.949238@eggemoggin.niobe.net>, <52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> Message-ID: <52AAD9C2.4040201@oracle.com> On 2013-12-12 20:13, mark.reinhold at oracle.com wrote: > 2013/12/12 2:12 -0800, stuart.marks at oracle.com: >> I agree that everybody **should** be aware of changes to the master, but mixing >> changeset notifications and discussion makes it more difficult for people to >> control how they process mail. For example, I do a lot of filtering of OpenJDK >> mail based on the mailing list to which it was delivered (using the Delivered-To >> header). If notifications were mixed with discussion, I'd have to apply an >> additional filter based on the subject line. This fails with replies to >> changeset notices, for example. > > Filtering out changeset notifications is easy -- just look for the > X-Hg-URL (or X-Hg-Changeset) header. Unless you're using the fine system that is Beehive. Then filtering on arbitrary headers is unsupported. Mikael From anthony.petrov at oracle.com Fri Dec 13 04:22:28 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Dec 2013 16:22:28 +0400 Subject: Initial forests for JDK 9 In-Reply-To: <20131212160246.760129@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212073544.949238@eggemoggin.niobe.net>, <52AA4654.6040709@oracle.com> <20131212160246.760129@eggemoggin.niobe.net> Message-ID: <52AAFC04.1010002@oracle.com> Thank you. -- best regards, Anthony On 12/13/2013 04:02 AM, mark.reinhold at oracle.com wrote: > 2013/12/12 7:27 -0800, jonathan.gibbons at oracle.com: >> On 12/12/2013 07:35 AM, mark.reinhold at oracle.com wrote: >>> I think the master forest is the exception. Everyone working on the >>> release should be aware of changes to the master, so notifications >>> for that forest should go to jdk9-dev, just as notifications for the >>> JDK 8 master went to jdk8-dev. >> >> I question why most folk working on the release should be aware of >> what is going on in the master. Most folk working on the release will >> be integrating up through the dev forest, so that is the forest that >> folk should be concerned about. If in this new world the master is just >> going to be a time-delayed, better tested, cache of the dev forest, then >> most folk will already be aware of the changes that have gone in. > > Hmm. Fair point. This is a new world -- or at least we're trying to > make it so. > >> Rather than sending messages to jdk9-dev, how about setting up >> jdk9-changes as a new alias, initially populated with the contents of >> the jdk9-dev alias, but allowing people to opt-in or opt-out of those >> messages as they choose, rather than always sending potentially unwanted >> messages such that they then have to go to the trouble of filtering out. > > Okay. How about we modify Iris's original proposal as follows: > > jdk9-changes Changes to the JDK 9 master forest > jdk9-all-changes Changes to all JDK 9 forests (including master) > > Change notifications for the master will only go to these two lists, > and specifically not to jdk9-dev. > > To keep things simple, all of these lists will be opt-in. > > Comments? > > - Mark > From stuart.marks at oracle.com Fri Dec 13 10:17:19 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 13 Dec 2013 10:17:19 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131212160246.760129@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212073544.949238@eggemoggin.niobe.net>, <52AA4654.6040709@oracle.com> <20131212160246.760129@eggemoggin.niobe.net> Message-ID: <52AB4F2F.1010404@oracle.com> On 12/12/13 4:02 PM, mark.reinhold at oracle.com wrote: > Okay. How about we modify Iris's original proposal as follows: > > jdk9-changes Changes to the JDK 9 master forest > jdk9-all-changes Changes to all JDK 9 forests (including master) > > Change notifications for the master will only go to these two lists, > and specifically not to jdk9-dev. > > To keep things simple, all of these lists will be opt-in. This looks great. I can't imagine why anybody would want jdk9-all-changes, but that's why these lists are opt-in, right? If somebody does find it useful, I have no objection. s'marks From tim.bell at oracle.com Fri Dec 13 10:27:42 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 13 Dec 2013 10:27:42 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52AB4F2F.1010404@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212073544.949238@eggemoggin.niobe.net>, <52AA4654.6040709@oracle.com> <20131212160246.760129@eggemoggin.niobe.net> <52AB4F2F.1010404@oracle.com> Message-ID: <52AB519E.60002@oracle.com> On 12/13/13 10:17 AM, Stuart Marks wrote: > > On 12/12/13 4:02 PM, mark.reinhold at oracle.com wrote: >> Okay. How about we modify Iris's original proposal as follows: >> >> jdk9-changes Changes to the JDK 9 master forest >> jdk9-all-changes Changes to all JDK 9 forests (including master) >> >> Change notifications for the master will only go to these two lists, >> and specifically not to jdk9-dev. >> >> To keep things simple, all of these lists will be opt-in. > > This looks great. I can't imagine why anybody would want > jdk9-all-changes, but that's why these lists are opt-in, right? If > somebody does find it useful, I have no objection. Users may not want to look at it day-to-day, but I can see value in having a full set of messages in the archives. Tim From joe.darcy at oracle.com Fri Dec 13 11:13:18 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 13 Dec 2013 11:13:18 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 Message-ID: <52AB5C4E.30705@oracle.com> Hello, With JDK 9 about to get underway, I'd like to propose several source code and regression test suite improvement efforts to tackle during this release. Over the years, the JDK code base has accumulated a bit of technical debt in various areas. In JDK 8, efforts have already been underway to pay down that technical debt including: * doclint cleanup: core libs is now doclint-clean and over 1,000 of the doclint warnings in client libs have been fixed [1] * javac lint cleanup: many lint issues have been resolved [2] and a number of lint categories are configured to cause fatal errors if they are found when building the jdk repo [3] * test stabilization: numerous regression tests in the jdk repo failed intermittently, ran for an unnecessarily long time, or suffered from other flaws that have been corrected [4] For JDK 9, I propose we complete these initiatives for the code in the langtools and jdk repositories (then possibly extend to jaxp, jaxws, etc.): * Source code in java.* and javax.* is doclint clean for public and protected elements and the docs build is configured to fail on a doclint issue. The generated javadoc is also tidy clean. * Java sources compile cleanly under "javac -Xlint:all -Werror" and the build is configured to fail if a lint issue is introduced. * There are no chronic intermittently failing tests and clean jdk test runs are a common occurrence. Reducing C/C++ build warnings would be a worthwhile goal too, but is complicated by the number of C/C++ compilers used across different supported platforms. In addition, various structural properties of javadoc should be regularized ({@code Foo} instead of Foo, package-info.java instead of package.html, @throws instead of @exception, etc.) and the Java source code should use contemporary coding idioms (lambda, diamond, etc.). There are thousands of lint and doclint issues remaining, but they can largely be addressed in parallel without interfering with each other, as was seen in JDK 8. While some effort will be required to get these issues addressed initially, once the source code and tests are in a clean state, we would benefit from tooling support to prevent certain classes of errors from being introduced. Comments? Thanks, -Joe [1] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint [2] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) [3] JDK-8024643 Turn on javac lint checking in building the jdk repo https://bugs.openjdk.java.net/browse/JDK-8024643 JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and try in jdk build https://bugs.openjdk.java.net/browse/JDK-8024603 [4] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization From jonathan.gibbons at oracle.com Fri Dec 13 11:42:36 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Dec 2013 11:42:36 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52AB5C4E.30705@oracle.com> References: <52AB5C4E.30705@oracle.com> Message-ID: <52AB632C.7030004@oracle.com> +lots -- Jon On 12/13/2013 11:13 AM, Joe Darcy wrote: > Hello, > > With JDK 9 about to get underway, I'd like to propose several source > code and regression test suite improvement efforts to tackle during > this release. > > Over the years, the JDK code base has accumulated a bit of technical > debt in various areas. In JDK 8, efforts have already been underway to > pay down that technical debt including: > > * doclint cleanup: core libs is now doclint-clean and over 1,000 of > the doclint warnings in client libs have been fixed [1] > > * javac lint cleanup: many lint issues have been resolved [2] and a > number of lint categories are configured to cause fatal errors if they > are found when building the jdk repo [3] > > * test stabilization: numerous regression tests in the jdk repo failed > intermittently, ran for an unnecessarily long time, or suffered from > other flaws that have been corrected [4] > > For JDK 9, I propose we complete these initiatives for the code in the > langtools and jdk repositories (then possibly extend to jaxp, jaxws, > etc.): > > * Source code in java.* and javax.* is doclint clean for public and > protected elements and the docs build is configured to fail on a > doclint issue. The generated javadoc is also tidy clean. > > * Java sources compile cleanly under "javac -Xlint:all -Werror" and > the build is configured to fail if a lint issue is introduced. > > * There are no chronic intermittently failing tests and clean jdk test > runs are a common occurrence. > > Reducing C/C++ build warnings would be a worthwhile goal too, but is > complicated by the number of C/C++ compilers used across different > supported platforms. In addition, various structural properties of > javadoc should be regularized ({@code Foo} instead of > Foo, package-info.java instead of package.html, @throws > instead of @exception, etc.) and the Java source code should use > contemporary coding idioms (lambda, diamond, etc.). > > There are thousands of lint and doclint issues remaining, but they can > largely be addressed in parallel without interfering with each other, > as was seen in JDK 8. While some effort will be required to get these > issues addressed initially, once the source code and tests are in a > clean state, we would benefit from tooling support to prevent certain > classes of errors from being introduced. > > Comments? > > Thanks, > > -Joe > > [1] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint > > [2] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) > > [3] JDK-8024643 Turn on javac lint checking in building the jdk repo > https://bugs.openjdk.java.net/browse/JDK-8024643 > > JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and > try in jdk build > https://bugs.openjdk.java.net/browse/JDK-8024603 > > [4] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization > From brian.goetz at oracle.com Fri Dec 13 12:38:35 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 13 Dec 2013 15:38:35 -0500 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52AB5C4E.30705@oracle.com> References: <52AB5C4E.30705@oracle.com> Message-ID: <46879FDC-07BF-48A5-9B28-04FC747E0A37@oracle.com> Would be great to have a continuously updated, publicly visible dashboard that displays (and hopefully, graphs trends in) the key cruft metrics we are looking to manage, so we can both see where the problems are and see progress in reducing them. On Dec 13, 2013, at 2:13 PM, Joe Darcy wrote: > Hello, > > With JDK 9 about to get underway, I'd like to propose several source code and regression test suite improvement efforts to tackle during this release. > > Over the years, the JDK code base has accumulated a bit of technical debt in various areas. In JDK 8, efforts have already been underway to pay down that technical debt including: > > * doclint cleanup: core libs is now doclint-clean and over 1,000 of the doclint warnings in client libs have been fixed [1] > > * javac lint cleanup: many lint issues have been resolved [2] and a number of lint categories are configured to cause fatal errors if they are found when building the jdk repo [3] > > * test stabilization: numerous regression tests in the jdk repo failed intermittently, ran for an unnecessarily long time, or suffered from other flaws that have been corrected [4] > > For JDK 9, I propose we complete these initiatives for the code in the langtools and jdk repositories (then possibly extend to jaxp, jaxws, etc.): > > * Source code in java.* and javax.* is doclint clean for public and protected elements and the docs build is configured to fail on a doclint issue. The generated javadoc is also tidy clean. > > * Java sources compile cleanly under "javac -Xlint:all -Werror" and the build is configured to fail if a lint issue is introduced. > > * There are no chronic intermittently failing tests and clean jdk test runs are a common occurrence. > > Reducing C/C++ build warnings would be a worthwhile goal too, but is complicated by the number of C/C++ compilers used across different supported platforms. In addition, various structural properties of javadoc should be regularized ({@code Foo} instead of Foo, package-info.java instead of package.html, @throws instead of @exception, etc.) and the Java source code should use contemporary coding idioms (lambda, diamond, etc.). > > There are thousands of lint and doclint issues remaining, but they can largely be addressed in parallel without interfering with each other, as was seen in JDK 8. While some effort will be required to get these issues addressed initially, once the source code and tests are in a clean state, we would benefit from tooling support to prevent certain classes of errors from being introduced. > > Comments? > > Thanks, > > -Joe > > [1] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint > > [2] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) > > [3] JDK-8024643 Turn on javac lint checking in building the jdk repo > https://bugs.openjdk.java.net/browse/JDK-8024643 > > JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and try in jdk build > https://bugs.openjdk.java.net/browse/JDK-8024603 > > [4] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization From mark.reinhold at oracle.com Fri Dec 13 12:46:28 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 13 Dec 2013 12:46:28 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <52AB4F2F.1010404@oracle.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212160246.760129@eggemoggin.niobe.net>, <52AB4F2F.1010404@oracle.com> Message-ID: <20131213124628.805204@eggemoggin.niobe.net> 2013/12/13 2:17 -0800, stuart.marks at oracle.com: > This looks great. I can't imagine why anybody would want jdk9-all-changes, but > that's why these lists are opt-in, right? I wondered that myself, and then noticed that the all-changes list for JDK 8 has 87 subscribers ... and I'm one of them. - Mark From mike.duigou at oracle.com Fri Dec 13 13:06:41 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 13 Dec 2013 13:06:41 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131213124628.805204@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212160246.760129@eggemoggin.niobe.net>, <52AB4F2F.1010404@oracle.com> <20131213124628.805204@eggemoggin.niobe.net> Message-ID: One possibility is that some CI or monitoring systems (CIA comes to mine) will use an email list as a poll trigger for VCS polling. Mike On Dec 13 2013, at 12:46 , mark.reinhold at oracle.com wrote: > 2013/12/13 2:17 -0800, stuart.marks at oracle.com: >> This looks great. I can't imagine why anybody would want jdk9-all-changes, but >> that's why these lists are opt-in, right? > > I wondered that myself, and then noticed that the all-changes list for > JDK 8 has 87 subscribers ... and I'm one of them. > > - Mark From mark.reinhold at oracle.com Fri Dec 13 14:27:43 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 13 Dec 2013 14:27:43 -0800 Subject: JDK 9 forests open Message-ID: <20131213142743.753214@eggemoggin.niobe.net> The JDK 9 forests are open, per my previous message [1], except that "hotspot" is replaced by "hs" in the names of the HotSpot forests. Handy links: http://hg.openjdk.java.net/jdk9/jdk9 (a.k.a. "master") http://hg.openjdk.java.net/jdk9/dev http://hg.openjdk.java.net/jdk9/client http://hg.openjdk.java.net/jdk9/hs http://hg.openjdk.java.net/jdk9/hs-comp http://hg.openjdk.java.net/jdk9/hs-emb http://hg.openjdk.java.net/jdk9/hs-gc http://hg.openjdk.java.net/jdk9/hs-rt The tip changesets have all been tagged "jdk9-b00", to make it easy to identify the exact starting point of this release. Mercurial changeset notifications will be sent to the appropriate jdk9-$FOREST-changes lists, except that notifications for the master will be sent to the jdk9-changes list. To receive the notifications for a particular forest, subscribe to the corresponding list on http://mail.openjdk.java.net. To receive the notifications for all forests, subscribe to the jdk9-all-changes list. The Census has been updated to include the Project's initial Authors, Committers, and Reviewers [2]. Please report any errors in the Census directly to me. For now the forests are open only for test stabilization, small bug fixes, and trivial enhancements. Features for the release will come in through the JEP Process, about which I'll have more to say soon. - Mark [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000107.html [2] http://openjdk.java.net/census#jdk9 From John.Coomes at oracle.com Fri Dec 13 16:13:15 2013 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 13 Dec 2013 16:13:15 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <20131213124628.805204@eggemoggin.niobe.net> References: <20131209212204.943183@eggemoggin.niobe.net> <20131212160246.760129@eggemoggin.niobe.net> <52AB4F2F.1010404@oracle.com> <20131213124628.805204@eggemoggin.niobe.net> Message-ID: <21163.41627.158896.619228@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: > 2013/12/13 2:17 -0800, stuart.marks at oracle.com: > > This looks great. I can't imagine why anybody would want jdk9-all-changes, but > > that's why these lists are opt-in, right? > > I wondered that myself, and then noticed that the all-changes list for > JDK 8 has 87 subscribers ... and I'm one of them. I'm also subscribed, but with delivery disabled, just to avoid each push triggering a moderation event (including an "awaiting moderation" message back to me). Pity the jdk9-all-changes moderator. -John From martijnverburg at gmail.com Sat Dec 14 04:28:45 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 14 Dec 2013 12:28:45 +0000 Subject: JDK 9 forests open In-Reply-To: <20131213142743.753214@eggemoggin.niobe.net> References: <20131213142743.753214@eggemoggin.niobe.net> Message-ID: Congrats Mark - great to see Java 9 up and running :-). Cheers, Martijn On 13 December 2013 22:27, wrote: > The JDK 9 forests are open, per my previous message [1], except that > "hotspot" is replaced by "hs" in the names of the HotSpot forests. > > Handy links: > > http://hg.openjdk.java.net/jdk9/jdk9 (a.k.a. "master") > http://hg.openjdk.java.net/jdk9/dev > http://hg.openjdk.java.net/jdk9/client > http://hg.openjdk.java.net/jdk9/hs > http://hg.openjdk.java.net/jdk9/hs-comp > http://hg.openjdk.java.net/jdk9/hs-emb > http://hg.openjdk.java.net/jdk9/hs-gc > http://hg.openjdk.java.net/jdk9/hs-rt > > The tip changesets have all been tagged "jdk9-b00", to make it easy > to identify the exact starting point of this release. > > Mercurial changeset notifications will be sent to the appropriate > jdk9-$FOREST-changes lists, except that notifications for the master > will be sent to the jdk9-changes list. To receive the notifications > for a particular forest, subscribe to the corresponding list on > http://mail.openjdk.java.net. To receive the notifications for all > forests, subscribe to the jdk9-all-changes list. > > The Census has been updated to include the Project's initial Authors, > Committers, and Reviewers [2]. Please report any errors in the Census > directly to me. > > For now the forests are open only for test stabilization, small bug > fixes, and trivial enhancements. Features for the release will come > in through the JEP Process, about which I'll have more to say soon. > > - Mark > > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000107.html > [2] http://openjdk.java.net/census#jdk9 > From martijnverburg at gmail.com Sat Dec 14 04:36:49 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 14 Dec 2013 12:36:49 +0000 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52AB632C.7030004@oracle.com> References: <52AB5C4E.30705@oracle.com> <52AB632C.7030004@oracle.com> Message-ID: +1, if issues can be raised and made public in JBUG and marked as low hanging fruit (or some similar designation) then this is great place for new contributors to start. Cheers, Martijn On 13 December 2013 19:42, Jonathan Gibbons wrote: > +lots > > -- Jon > > > > On 12/13/2013 11:13 AM, Joe Darcy wrote: > >> Hello, >> >> With JDK 9 about to get underway, I'd like to propose several source code >> and regression test suite improvement efforts to tackle during this release. >> >> Over the years, the JDK code base has accumulated a bit of technical debt >> in various areas. In JDK 8, efforts have already been underway to pay down >> that technical debt including: >> >> * doclint cleanup: core libs is now doclint-clean and over 1,000 of the >> doclint warnings in client libs have been fixed [1] >> >> * javac lint cleanup: many lint issues have been resolved [2] and a >> number of lint categories are configured to cause fatal errors if they are >> found when building the jdk repo [3] >> >> * test stabilization: numerous regression tests in the jdk repo failed >> intermittently, ran for an unnecessarily long time, or suffered from other >> flaws that have been corrected [4] >> >> For JDK 9, I propose we complete these initiatives for the code in the >> langtools and jdk repositories (then possibly extend to jaxp, jaxws, etc.): >> >> * Source code in java.* and javax.* is doclint clean for public and >> protected elements and the docs build is configured to fail on a doclint >> issue. The generated javadoc is also tidy clean. >> >> * Java sources compile cleanly under "javac -Xlint:all -Werror" and the >> build is configured to fail if a lint issue is introduced. >> >> * There are no chronic intermittently failing tests and clean jdk test >> runs are a common occurrence. >> >> Reducing C/C++ build warnings would be a worthwhile goal too, but is >> complicated by the number of C/C++ compilers used across different >> supported platforms. In addition, various structural properties of javadoc >> should be regularized ({@code Foo} instead of Foo, >> package-info.java instead of package.html, @throws instead of @exception, >> etc.) and the Java source code should use contemporary coding idioms >> (lambda, diamond, etc.). >> >> There are thousands of lint and doclint issues remaining, but they can >> largely be addressed in parallel without interfering with each other, as >> was seen in JDK 8. While some effort will be required to get these issues >> addressed initially, once the source code and tests are in a clean state, >> we would benefit from tooling support to prevent certain classes of errors >> from being introduced. >> >> Comments? >> >> Thanks, >> >> -Joe >> >> [1] https://bugs.openjdk.java.net/issues/?jql=project%20%3D% >> 20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20% >> 3D%20Fixed%20and%20labels%20%3D%20doclint >> >> [2] https://bugs.openjdk.java.net/issues/?jql=project%20%3D% >> 20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20% >> 3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) >> >> [3] JDK-8024643 Turn on javac lint checking in building the jdk repo >> https://bugs.openjdk.java.net/browse/JDK-8024643 >> >> JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and >> try in jdk build >> https://bugs.openjdk.java.net/browse/JDK-8024603 >> >> [4] https://bugs.openjdk.java.net/issues/?jql=project%20%3D% >> 20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20% >> 3D%20Fixed%20and%20labels%20%3D%20teststabilization >> > > From joe.darcy at oracle.com Sat Dec 14 13:49:52 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 14 Dec 2013 13:49:52 -0800 Subject: JDK 9 forests open In-Reply-To: <20131213142743.753214@eggemoggin.niobe.net> References: <20131213142743.753214@eggemoggin.niobe.net> Message-ID: <52ACD280.8040101@oracle.com> For JDK 9 development, make sure to update any local copies of jcheck to one that recognizes the "jdk9-*" tags: http://openjdk.java.net/projects/code-tools/jcheck/ -Joe On 12/13/2013 02:27 PM, mark.reinhold at oracle.com wrote: > The JDK 9 forests are open, per my previous message [1], except that > "hotspot" is replaced by "hs" in the names of the HotSpot forests. > > Handy links: > > http://hg.openjdk.java.net/jdk9/jdk9 (a.k.a. "master") > http://hg.openjdk.java.net/jdk9/dev > http://hg.openjdk.java.net/jdk9/client > http://hg.openjdk.java.net/jdk9/hs > http://hg.openjdk.java.net/jdk9/hs-comp > http://hg.openjdk.java.net/jdk9/hs-emb > http://hg.openjdk.java.net/jdk9/hs-gc > http://hg.openjdk.java.net/jdk9/hs-rt > > The tip changesets have all been tagged "jdk9-b00", to make it easy > to identify the exact starting point of this release. > > Mercurial changeset notifications will be sent to the appropriate > jdk9-$FOREST-changes lists, except that notifications for the master > will be sent to the jdk9-changes list. To receive the notifications > for a particular forest, subscribe to the corresponding list on > http://mail.openjdk.java.net. To receive the notifications for all > forests, subscribe to the jdk9-all-changes list. > > The Census has been updated to include the Project's initial Authors, > Committers, and Reviewers [2]. Please report any errors in the Census > directly to me. > > For now the forests are open only for test stabilization, small bug > fixes, and trivial enhancements. Features for the release will come > in through the JEP Process, about which I'll have more to say soon. > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000107.html > [2] http://openjdk.java.net/census#jdk9 From mark.reinhold at oracle.com Sat Dec 14 13:51:34 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 14 Dec 2013 13:51:34 -0800 Subject: Initial forests for JDK 9 In-Reply-To: <21163.41627.158896.619228@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> References: <20131209212204.943183@eggemoggin.niobe.net>, <20131212160246.760129@eggemoggin.niobe.net>, <52AB4F2F.1010404@oracle.com>, <20131213124628.805204@eggemoggin.niobe.net>, <21163.41627.158896.619228@dhcp-santaclara22-3fl-west-10-132-189-151.usdhcp.oraclecorp.com> Message-ID: <20131214135134.101027@eggemoggin.niobe.net> 2013/12/13 8:13 -0800, john.coomes at oracle.com: > mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: >> 2013/12/13 2:17 -0800, stuart.marks at oracle.com: >> > This looks great. I can't imagine why anybody would want jdk9-all-changes, but >> > that's why these lists are opt-in, right? >> >> I wondered that myself, and then noticed that the all-changes list for >> JDK 8 has 87 subscribers ... and I'm one of them. > > I'm also subscribed, but with delivery disabled, just to avoid each > push triggering a moderation event (including an "awaiting moderation" > message back to me). Pity the jdk9-all-changes moderator. The sender filters on all the -changes lists have now been set up to accept messages from all JDK 9 committers (and reviewers), so moderation events should not be a problem. - Mark From mike.duigou at oracle.com Mon Dec 16 13:57:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 16 Dec 2013 13:57:14 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52AB5C4E.30705@oracle.com> References: <52AB5C4E.30705@oracle.com> Message-ID: <57D08916-6B53-4CBB-AFFC-CD9BBB6DE379@oracle.com> On Dec 13 2013, at 11:13 , Joe Darcy wrote: > Hello, > > With JDK 9 about to get underway, I'd like to propose several source code and regression test suite improvement efforts to tackle during this release. > > Over the years, the JDK code base has accumulated a bit of technical debt in various areas. In JDK 8, efforts have already been underway to pay down that technical debt including: > For JDK 9, I propose we complete these initiatives for the code in the langtools and jdk repositories (then possibly extend to jaxp, jaxws, etc.): > Reducing C/C++ build warnings would be a worthwhile goal too, but is complicated by the number of C/C++ compilers used across different supported platforms. On this topic I believe that one aspect we can tackle is to reduce the number of different sets of compiler settings across modules (see compilation of SCTP native library for an example) used and standardize on a set of compiler options and warnings. There's also the possibility to enable additional warnings on certain platforms that may provide benefit across all platforms once fixed. eg. GCC -Wformat -Wformat-security etc. The blocking issue here would be that using these options potentially imposes a requirement of newer compiler versions on some platforms. Mike From joe.darcy at oracle.com Mon Dec 16 17:29:31 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 16 Dec 2013 17:29:31 -0800 Subject: Updated jtreg build in the works ahead of JDK_MINOR_VERSION increment Message-ID: <52AFA8FB.8080406@oracle.com> FYI, one of the to-do items for early in a feature release is incrementing JDK_MINOR_VERSION, in the case of JDK 9, from "8" to "9". Test builds with this change revealed a bad interaction between the TestNG regression tests invoked through jtreg, leading to hundreds of the TestNGs tests in the langtools and jdk repositories spuriously failing after the increment. A fix for the jtreg issue is in the works; we're going to hold off pushing the JDK_MINOR_VERSION increment changeset until the corrected jtreg is available. -Joe From jonathan.gibbons at oracle.com Mon Dec 16 17:33:53 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 16 Dec 2013 17:33:53 -0800 Subject: Updated jtreg build in the works ahead of JDK_MINOR_VERSION increment In-Reply-To: <52AFA8FB.8080406@oracle.com> References: <52AFA8FB.8080406@oracle.com> Message-ID: <52AFAA01.2000705@oracle.com> On 12/16/2013 05:29 PM, Joe Darcy wrote: > the works; we're going to hold off pushing the JDK_MINOR_VERSION > increment changeset until the corrected jtreg is available. > > -Joe For those building jtreg from source, the jtreg fix is available (in the jtreg repo). Joe is just referring to the availability of binaries within Oracle. -- Jon From martijnverburg at gmail.com Tue Dec 17 04:00:35 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 17 Dec 2013 12:00:35 +0000 Subject: Updated jtreg build in the works ahead of JDK_MINOR_VERSION increment In-Reply-To: <52AFAA01.2000705@oracle.com> References: <52AFA8FB.8080406@oracle.com> <52AFAA01.2000705@oracle.com> Message-ID: Hi all, We'll shortly be making binary builds of jtreg available on an Adopt OpenJDK server. In the mean time you can be brave and grab it right off the CI instance: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/ Kudos to Mani Sarkar for getting this up and running. More to follow Cheers, Martijn On 17 December 2013 01:33, Jonathan Gibbons wrote: > On 12/16/2013 05:29 PM, Joe Darcy wrote: > >> the works; we're going to hold off pushing the JDK_MINOR_VERSION >> increment changeset until the corrected jtreg is available. >> >> -Joe >> > > > For those building jtreg from source, the jtreg fix is available (in the > jtreg repo). Joe is just referring to the availability of binaries within > Oracle. > > -- Jon > From stuart.marks at oracle.com Tue Dec 17 13:57:43 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 Dec 2013 13:57:43 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52AB5C4E.30705@oracle.com> References: <52AB5C4E.30705@oracle.com> Message-ID: <52B0C8D7.50409@oracle.com> Hi Joe, +0.9999998! :-) I think that it's a fine goal to complete all of the efforts we began in JDK 8. But there should be some priorities assigned here. As you know, I'm a champion of warnings cleanup. But I think dealing with the test failures is *more* important than warnings. If we're warnings-free at the end of JDK 9 but we still have test failures, I think we'd have missed the boat. As you know, the situation is essentially that we cannot get a complete test run without at least one test failure. This makes it difficult to assess the quality of a change being tested, it wastes time, generally slows things down, and is a barrier to introducing a more streamlined system for building, testing, and integration. I'd like to see us focus our efforts at getting us test-failure-free as quickly as feasible in the JDK 9 development cycle, while continuing warnings and doclint cleanup as a side activity. Thanks, s'marks On 12/13/13 11:13 AM, Joe Darcy wrote: > Hello, > > With JDK 9 about to get underway, I'd like to propose several source code and > regression test suite improvement efforts to tackle during this release. > > Over the years, the JDK code base has accumulated a bit of technical debt in > various areas. In JDK 8, efforts have already been underway to pay down that > technical debt including: > > * doclint cleanup: core libs is now doclint-clean and over 1,000 of the doclint > warnings in client libs have been fixed [1] > > * javac lint cleanup: many lint issues have been resolved [2] and a number of > lint categories are configured to cause fatal errors if they are found when > building the jdk repo [3] > > * test stabilization: numerous regression tests in the jdk repo failed > intermittently, ran for an unnecessarily long time, or suffered from other flaws > that have been corrected [4] > > For JDK 9, I propose we complete these initiatives for the code in the langtools > and jdk repositories (then possibly extend to jaxp, jaxws, etc.): > > * Source code in java.* and javax.* is doclint clean for public and protected > elements and the docs build is configured to fail on a doclint issue. The > generated javadoc is also tidy clean. > > * Java sources compile cleanly under "javac -Xlint:all -Werror" and the build is > configured to fail if a lint issue is introduced. > > * There are no chronic intermittently failing tests and clean jdk test runs are > a common occurrence. > > Reducing C/C++ build warnings would be a worthwhile goal too, but is complicated > by the number of C/C++ compilers used across different supported platforms. In > addition, various structural properties of javadoc should be regularized ({@code > Foo} instead of Foo, package-info.java instead of package.html, > @throws instead of @exception, etc.) and the Java source code should use > contemporary coding idioms (lambda, diamond, etc.). > > There are thousands of lint and doclint issues remaining, but they can largely > be addressed in parallel without interfering with each other, as was seen in JDK > 8. While some effort will be required to get these issues addressed initially, > once the source code and tests are in a clean state, we would benefit from > tooling support to prevent certain classes of errors from being introduced. > > Comments? > > Thanks, > > -Joe > > [1] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint > > > [2] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) > > > [3] JDK-8024643 Turn on javac lint checking in building the jdk repo > https://bugs.openjdk.java.net/browse/JDK-8024643 > > JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and try in > jdk build > https://bugs.openjdk.java.net/browse/JDK-8024603 > > [4] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization > From joe.darcy at oracle.com Tue Dec 17 16:20:43 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 17 Dec 2013 16:20:43 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52B0C8D7.50409@oracle.com> References: <52AB5C4E.30705@oracle.com> <52B0C8D7.50409@oracle.com> Message-ID: <52B0EA5B.8090201@oracle.com> Hi Stuart, On 12/17/2013 01:57 PM, Stuart Marks wrote: > Hi Joe, > > +0.9999998! :-) That's close enough to 1.0 for me ;-) > > I think that it's a fine goal to complete all of the efforts we began > in JDK 8. But there should be some priorities assigned here. As you > know, I'm a champion of warnings cleanup. But I think dealing with the > test failures is *more* important than warnings. If we're > warnings-free at the end of JDK 9 but we still have test failures, I > think we'd have missed the boat. > > As you know, the situation is essentially that we cannot get a > complete test run without at least one test failure. This makes it > difficult to assess the quality of a change being tested, it wastes > time, generally slows things down, and is a barrier to introducing a > more streamlined system for building, testing, and integration. > > I'd like to see us focus our efforts at getting us test-failure-free > as quickly as feasible in the JDK 9 development cycle, while > continuing warnings and doclint cleanup as a side activity. I agree that in terms of impact, test stabilization is more important. However, expanding on your sentiment, I don't think warnings cleanup and test cleanup are mutually exclusive. For example, while waiting for your test run to come back, you can work on knocking back some warnings :-) -Joe > > Thanks, > > s'marks > > > > On 12/13/13 11:13 AM, Joe Darcy wrote: >> Hello, >> >> With JDK 9 about to get underway, I'd like to propose several source >> code and >> regression test suite improvement efforts to tackle during this release. >> >> Over the years, the JDK code base has accumulated a bit of technical >> debt in >> various areas. In JDK 8, efforts have already been underway to pay >> down that >> technical debt including: >> >> * doclint cleanup: core libs is now doclint-clean and over 1,000 of >> the doclint >> warnings in client libs have been fixed [1] >> >> * javac lint cleanup: many lint issues have been resolved [2] and a >> number of >> lint categories are configured to cause fatal errors if they are >> found when >> building the jdk repo [3] >> >> * test stabilization: numerous regression tests in the jdk repo failed >> intermittently, ran for an unnecessarily long time, or suffered from >> other flaws >> that have been corrected [4] >> >> For JDK 9, I propose we complete these initiatives for the code in >> the langtools >> and jdk repositories (then possibly extend to jaxp, jaxws, etc.): >> >> * Source code in java.* and javax.* is doclint clean for public and >> protected >> elements and the docs build is configured to fail on a doclint issue. >> The >> generated javadoc is also tidy clean. >> >> * Java sources compile cleanly under "javac -Xlint:all -Werror" and >> the build is >> configured to fail if a lint issue is introduced. >> >> * There are no chronic intermittently failing tests and clean jdk >> test runs are >> a common occurrence. >> >> Reducing C/C++ build warnings would be a worthwhile goal too, but is >> complicated >> by the number of C/C++ compilers used across different supported >> platforms. In >> addition, various structural properties of javadoc should be >> regularized ({@code >> Foo} instead of Foo, package-info.java instead of >> package.html, >> @throws instead of @exception, etc.) and the Java source code should use >> contemporary coding idioms (lambda, diamond, etc.). >> >> There are thousands of lint and doclint issues remaining, but they >> can largely >> be addressed in parallel without interfering with each other, as was >> seen in JDK >> 8. While some effort will be required to get these issues addressed >> initially, >> once the source code and tests are in a clean state, we would benefit >> from >> tooling support to prevent certain classes of errors from being >> introduced. >> >> Comments? >> >> Thanks, >> >> -Joe >> >> [1] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint >> >> >> >> [2] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) >> >> >> >> [3] JDK-8024643 Turn on javac lint checking in building the jdk repo >> https://bugs.openjdk.java.net/browse/JDK-8024643 >> >> JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, >> and try in >> jdk build >> https://bugs.openjdk.java.net/browse/JDK-8024603 >> >> [4] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization >> >> From Alan.Bateman at oracle.com Wed Dec 18 08:36:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Dec 2013 16:36:16 +0000 Subject: JDK 9 forests open In-Reply-To: <20131213142743.753214@eggemoggin.niobe.net> References: <20131213142743.753214@eggemoggin.niobe.net> Message-ID: <52B1CF00.9030206@oracle.com> On 13/12/2013 22:27, mark.reinhold at oracle.com wrote: > The JDK 9 forests are open, per my previous message [1], except that > "hotspot" is replaced by "hs" in the names of the HotSpot forests. > Just to double check one thing (and this ties into the thread on jdk8-dev on Managing parallel change). The jdk9 forests seem to be created from jdk8-b120. If I read the mails correctly then this means that anything pushed to a jdk8 integration forest that didn't make b120 needs to be pushed to one of the jdk9 integration forests, right? I just want to check because I see several changes in jdk8/tl that are not in jdk9/dev (not yet anyway). -Alan From joe.darcy at oracle.com Wed Dec 18 11:41:50 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 18 Dec 2013 11:41:50 -0800 Subject: JDK 9 forests open In-Reply-To: <52B1CF00.9030206@oracle.com> References: <20131213142743.753214@eggemoggin.niobe.net> <52B1CF00.9030206@oracle.com> Message-ID: <52B1FA7E.4010806@oracle.com> On 12/18/2013 08:36 AM, Alan Bateman wrote: > On 13/12/2013 22:27, mark.reinhold at oracle.com wrote: >> The JDK 9 forests are open, per my previous message [1], except that >> "hotspot" is replaced by "hs" in the names of the HotSpot forests. >> > Just to double check one thing (and this ties into the thread on > jdk8-dev on Managing parallel change). > > The jdk9 forests seem to be created from jdk8-b120. If I read the > mails correctly then this means that anything pushed to a jdk8 > integration forest that didn't make b120 needs to be pushed to one of > the jdk9 integration forests, right? I just want to check because I > see several changes in jdk8/tl that are not in jdk9/dev (not yet anyway). > Correct. -Joe From darryl.mocek at oracle.com Wed Dec 18 13:40:14 2013 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Wed, 18 Dec 2013 13:40:14 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52AB5C4E.30705@oracle.com> References: <52AB5C4E.30705@oracle.com> Message-ID: <52B2163E.8060302@oracle.com> We should also update the pertinent information on the official Oracle pages so others working on OpenJDK can have a reference. For example, this page on Javadoc style: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#styleguide still recommends using as the way to comment keywords and names in Javadocs. There's also the "Code Conventions for the Java Programming Language" (http://www.oracle.com/technetwork/java/codeconv-138413.html) which was last revised and updated on April 20, 1999 (The PDF is dated 1997). This should be updated to support modern programming practices as well as new Java features. As the web page states: "Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.". Darryl On 12/13/2013 11:13 AM, Joe Darcy wrote: > Hello, > > With JDK 9 about to get underway, I'd like to propose several source > code and regression test suite improvement efforts to tackle during > this release. > > Over the years, the JDK code base has accumulated a bit of technical > debt in various areas. In JDK 8, efforts have already been underway to > pay down that technical debt including: > > * doclint cleanup: core libs is now doclint-clean and over 1,000 of > the doclint warnings in client libs have been fixed [1] > > * javac lint cleanup: many lint issues have been resolved [2] and a > number of lint categories are configured to cause fatal errors if they > are found when building the jdk repo [3] > > * test stabilization: numerous regression tests in the jdk repo failed > intermittently, ran for an unnecessarily long time, or suffered from > other flaws that have been corrected [4] > > For JDK 9, I propose we complete these initiatives for the code in the > langtools and jdk repositories (then possibly extend to jaxp, jaxws, > etc.): > > * Source code in java.* and javax.* is doclint clean for public and > protected elements and the docs build is configured to fail on a > doclint issue. The generated javadoc is also tidy clean. > > * Java sources compile cleanly under "javac -Xlint:all -Werror" and > the build is configured to fail if a lint issue is introduced. > > * There are no chronic intermittently failing tests and clean jdk test > runs are a common occurrence. > > Reducing C/C++ build warnings would be a worthwhile goal too, but is > complicated by the number of C/C++ compilers used across different > supported platforms. In addition, various structural properties of > javadoc should be regularized ({@code Foo} instead of > Foo, package-info.java instead of package.html, @throws > instead of @exception, etc.) and the Java source code should use > contemporary coding idioms (lambda, diamond, etc.). > > There are thousands of lint and doclint issues remaining, but they can > largely be addressed in parallel without interfering with each other, > as was seen in JDK 8. While some effort will be required to get these > issues addressed initially, once the source code and tests are in a > clean state, we would benefit from tooling support to prevent certain > classes of errors from being introduced. > > Comments? > > Thanks, > > -Joe > > [1] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint > > [2] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) > > [3] JDK-8024643 Turn on javac lint checking in building the jdk repo > https://bugs.openjdk.java.net/browse/JDK-8024643 > > JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and > try in jdk build > https://bugs.openjdk.java.net/browse/JDK-8024603 > > [4] > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization > From david.holmes at oracle.com Wed Dec 18 23:33:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Dec 2013 17:33:52 +1000 Subject: Initial forests for JDK 9 In-Reply-To: <42b71cbb-0395-466f-9436-f65ec7ca9c54@default> References: <20131209212204.943183@eggemoggin.niobe.net>> <<20131212073544.949238@eggemoggin.niobe.net>> <<52A9FC78.3060207@oracle.com> <20131212111329.371571@eggemoggin.niobe.net> <52AA2313.3040903@oracle.com> <49c0385e-da85-4036-979f-5b41ee9ddc8f@default> <52AA27EC.2040708@oracle.com> <42b71cbb-0395-466f-9436-f65ec7ca9c54@default> Message-ID: <52B2A160.7090804@oracle.com> Catching up after vacation ... I'm not sure where this ended up or what new mailing lists I might need to subscribe to :( On 13/12/2013 7:18 AM, Iris Clark wrote: >>>>> jdk9-hs-emb-changes: hotspot-runtime-dev >>>> There should be an Embedded team alias in addition to >>>> hotspot-runtime-dev for this one.Yes, Runtime wants to know about the >>>> Embedded team's work, but I think the Embedded team would also like >>>> to know... :-) >>> Sounds reasonable. Which openjdk mailing list do they use: They don't! :) We subscribe to the appropriate hotspot-dev OpenJDK lists. SE Embedded, being a proprietary Oracle product, does not have an OpenJDK discussion list. >>> http://mail.openjdk.java.net/mailman/listinfo > >> Oh.... Good question... Adding Gary Collins to this thread... > > Right now, hsx/hotspot-emb on hg.openjdk goes to hotspot-runtime-dev only. Given we sometimes make compiler and gc related changes, in addition to runtime related ones, it may make more sense to send these to hotspot-dev instead. But that increases the number of people for which any given email is uninteresting. Leaving it as-is seems fine to me. Thanks, David > iris > From Alan.Bateman at oracle.com Thu Dec 19 03:55:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Dec 2013 11:55:35 +0000 Subject: jdk9/dev requires a jdk8 build as boot JDK Message-ID: <52B2DEB7.7020905@oracle.com> Just a heads-up that there are changes in jdk9/dev that require that it be built with a recent JDK 8 build as the boot JDK (configure --with-boot-jdk ). -Alan. From paul.sandoz at oracle.com Thu Dec 19 04:16:28 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 19 Dec 2013 13:16:28 +0100 Subject: jdk9/dev requires a jdk8 build as boot JDK In-Reply-To: <52B2DEB7.7020905@oracle.com> References: <52B2DEB7.7020905@oracle.com> Message-ID: <6B906BC7-A757-45A5-A8A4-54A8DA2AE0AD@oracle.com> On Dec 19, 2013, at 12:55 PM, Alan Bateman wrote: > > Just a heads-up that there are changes in jdk9/dev that require that it be built with a recent JDK 8 build as the boot JDK (configure --with-boot-jdk ). > Right, due to recent code clean ups of langtool code. Just found that out about 1h ago. I reused JDK 8 EA 120 build without an issue: https://jdk8.java.net/download.html Paul. From roger.riggs at oracle.com Thu Dec 19 06:41:37 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 19 Dec 2013 09:41:37 -0500 Subject: jdk9/dev requires a jdk8 build as boot JDK In-Reply-To: <52B2DEB7.7020905@oracle.com> References: <52B2DEB7.7020905@oracle.com> Message-ID: <52B305A1.3000308@oracle.com> I ran into that too; should configure be modified? On 12/19/2013 6:55 AM, Alan Bateman wrote: > > Just a heads-up that there are changes in jdk9/dev that require that > it be built with a recent JDK 8 build as the boot JDK (configure > --with-boot-jdk ). > > -Alan. From chris.hegarty at oracle.com Thu Dec 19 06:55:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Dec 2013 14:55:22 +0000 Subject: jdk9/dev requires a jdk8 build as boot JDK In-Reply-To: <52B305A1.3000308@oracle.com> References: <52B2DEB7.7020905@oracle.com> <52B305A1.3000308@oracle.com> Message-ID: On 19 Dec 2013, at 14:41, roger riggs wrote: > I ran into that too; should configure be modified? Review just out on build-dev http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html -Chris. > On 12/19/2013 6:55 AM, Alan Bateman wrote: >> >> Just a heads-up that there are changes in jdk9/dev that require that it be built with a recent JDK 8 build as the boot JDK (configure --with-boot-jdk ). >> >> -Alan. > From joel.franck at oracle.com Thu Dec 19 07:05:41 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 19 Dec 2013 16:05:41 +0100 Subject: jdk9/dev requires a jdk8 build as boot JDK In-Reply-To: <6B906BC7-A757-45A5-A8A4-54A8DA2AE0AD@oracle.com> References: <52B2DEB7.7020905@oracle.com> <6B906BC7-A757-45A5-A8A4-54A8DA2AE0AD@oracle.com> Message-ID: <20131219150541.GA27611@oracle.com> On 2013-12-19, Paul Sandoz wrote: > > On Dec 19, 2013, at 12:55 PM, Alan Bateman wrote: > > > > > Just a heads-up that there are changes in jdk9/dev that require that it be built with a recent JDK 8 build as the boot JDK (configure --with-boot-jdk ). > > > > Right, due to recent code clean ups of langtool code. Just found that out about 1h ago. I reused JDK 8 EA 120 build without an issue: > > https://jdk8.java.net/download.html > I think this was a bit to early to require 8. Filed: https://bugs.openjdk.java.net/browse/JDK-8030807 cheers /Joel From joe.darcy at oracle.com Fri Dec 20 14:15:14 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 20 Dec 2013 14:15:14 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52B2163E.8060302@oracle.com> References: <52AB5C4E.30705@oracle.com> <52B2163E.8060302@oracle.com> Message-ID: <52B4C172.1010800@oracle.com> Hi Darryl, It is certainly fair to raise the point that our official code conventions and javadoc style are long (really long!) out of date and in need to revising / rewriting to capture current recommended practices. I concede these documents should be revised, but I won't promise a time-line for doing so ;-) -Joe On 12/18/2013 01:40 PM, Darryl Mocek wrote: > We should also update the pertinent information on the official Oracle > pages so others working on OpenJDK can have a reference. For example, > this page on Javadoc style: > http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#styleguide > still recommends using as the way to comment keywords > and names in Javadocs. There's also the "Code Conventions for the > Java Programming Language" > (http://www.oracle.com/technetwork/java/codeconv-138413.html) which > was last revised and updated on April 20, 1999 (The PDF is dated > 1997). This should be updated to support modern programming practices > as well as new Java features. As the web page states: "Code > conventions improve the readability of the software, allowing > engineers to understand new code more quickly and thoroughly.". > > Darryl > > On 12/13/2013 11:13 AM, Joe Darcy wrote: >> Hello, >> >> With JDK 9 about to get underway, I'd like to propose several source >> code and regression test suite improvement efforts to tackle during >> this release. >> >> Over the years, the JDK code base has accumulated a bit of technical >> debt in various areas. In JDK 8, efforts have already been underway >> to pay down that technical debt including: >> >> * doclint cleanup: core libs is now doclint-clean and over 1,000 of >> the doclint warnings in client libs have been fixed [1] >> >> * javac lint cleanup: many lint issues have been resolved [2] and a >> number of lint categories are configured to cause fatal errors if >> they are found when building the jdk repo [3] >> >> * test stabilization: numerous regression tests in the jdk repo >> failed intermittently, ran for an unnecessarily long time, or >> suffered from other flaws that have been corrected [4] >> >> For JDK 9, I propose we complete these initiatives for the code in >> the langtools and jdk repositories (then possibly extend to jaxp, >> jaxws, etc.): >> >> * Source code in java.* and javax.* is doclint clean for public and >> protected elements and the docs build is configured to fail on a >> doclint issue. The generated javadoc is also tidy clean. >> >> * Java sources compile cleanly under "javac -Xlint:all -Werror" and >> the build is configured to fail if a lint issue is introduced. >> >> * There are no chronic intermittently failing tests and clean jdk >> test runs are a common occurrence. >> >> Reducing C/C++ build warnings would be a worthwhile goal too, but is >> complicated by the number of C/C++ compilers used across different >> supported platforms. In addition, various structural properties of >> javadoc should be regularized ({@code Foo} instead of >> Foo, package-info.java instead of package.html, @throws >> instead of @exception, etc.) and the Java source code should use >> contemporary coding idioms (lambda, diamond, etc.). >> >> There are thousands of lint and doclint issues remaining, but they >> can largely be addressed in parallel without interfering with each >> other, as was seen in JDK 8. While some effort will be required to >> get these issues addressed initially, once the source code and tests >> are in a clean state, we would benefit from tooling support to >> prevent certain classes of errors from being introduced. >> >> Comments? >> >> Thanks, >> >> -Joe >> >> [1] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint >> >> [2] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) >> >> [3] JDK-8024643 Turn on javac lint checking in building the jdk repo >> https://bugs.openjdk.java.net/browse/JDK-8024643 >> >> JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, >> and try in jdk build >> https://bugs.openjdk.java.net/browse/JDK-8024603 >> >> [4] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization >> > From sergey.lugovoy at oracle.com Thu Dec 26 05:51:45 2013 From: sergey.lugovoy at oracle.com (Serge) Date: Thu, 26 Dec 2013 17:51:45 +0400 Subject: RFR: JDK-8030709 : Tidy warnings cleanup for java.lang package Message-ID: <52BC3471.9020007@oracle.com> Hi all. Please review the fix http://cr.openjdk.java.net/~yan/8030709/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8030709 This patch cleanup tidy warnings for generated html documentation, and do not affect the appearance of the documentation. Best regards, Serge V. Lugovoy From alejandro.murillo at oracle.com Fri Dec 27 10:27:21 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 27 Dec 2013 11:27:21 -0700 Subject: [jdk9] Heads up: Hotspot version string output is changing to match that of the JDK Message-ID: <52BDC689.8090009@oracle.com> There is no longer a separate hotspot version in jdk9 (see attached email for details), so the version string produced by java -version and java -Xinternalversion in jdk9 builds will be changed to match that of the JDK (as was the case before Hotspot express). And also to add additional info for non promoted or developers builds. The details of this change are described here: https://bugs.openjdk.java.net/browse/JDK-8030011 a webrev with the fix will be sent soon. Let me know if you have any feedback/suggestion thanks -- Alejandro -------------- next part -------------- An embedded message was scrubbed... From: John Coomes Subject: proposal - dissolve the OpenJDK hsx Project after jdk8 ships Date: Tue, 10 Dec 2013 13:02:38 -0800 Size: 6275 Url: http://mail.openjdk.java.net/pipermail/jdk9-dev/attachments/20131227/7311a056/AttachedMessage.nws From jeremymanson at google.com Fri Dec 27 12:24:39 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 27 Dec 2013 12:24:39 -0800 Subject: [jdk9] Heads up: Hotspot version string output is changing to match that of the JDK In-Reply-To: <52BDC689.8090009@oracle.com> References: <52BDC689.8090009@oracle.com> Message-ID: A policy question: Does this mean that we can no longer expect large Hotspot changes in a single JDK release? JDK7 has seen HS21->22->23->24; some of those leaps were pretty substantial. Jeremy On Fri, Dec 27, 2013 at 10:27 AM, Alejandro E Murillo < alejandro.murillo at oracle.com> wrote: > > There is no longer a separate hotspot version in jdk9 (see attached email > for details), > so the version string produced by java -version and java -Xinternalversion > in jdk9 builds > will be changed to match that of the JDK (as was the case before Hotspot > express). > And also to add additional info for non promoted or developers builds. > > The details of this change are described here: > > https://bugs.openjdk.java.net/browse/JDK-8030011 > > a webrev with the fix will be sent soon. > Let me know if you have any feedback/suggestion > > thanks > > -- > Alejandro > > From joe.darcy at oracle.com Tue Dec 17 16:14:49 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 17 Dec 2013 16:14:49 -0800 Subject: Proposed source code and regression test suite improvement projects for JDK 9 In-Reply-To: <52B0C8D7.50409@oracle.com> References: <52AB5C4E.30705@oracle.com> <52B0C8D7.50409@oracle.com> Message-ID: <52B0E8F9.2090106@oracle.com> Hi Stuart, On 12/17/2013 01:57 PM, Stuart Marks wrote: > Hi Joe, > > +0.9999998! :-) That's close enough to 1.0 for me ;-) > > I think that it's a fine goal to complete all of the efforts we began > in JDK 8. But there should be some priorities assigned here. As you > know, I'm a champion of warnings cleanup. But I think dealing with the > test failures is *more* important than warnings. If we're > warnings-free at the end of JDK 9 but we still have test failures, I > think we'd have missed the boat. > > As you know, the situation is essentially that we cannot get a > complete test run without at least one test failure. This makes it > difficult to assess the quality of a change being tested, it wastes > time, generally slows things down, and is a barrier to introducing a > more streamlined system for building, testing, and integration. > > I'd like to see us focus our efforts at getting us test-failure-free > as quickly as feasible in the JDK 9 development cycle, while > continuing warnings and doclint cleanup as a side activity. I agree that in terms of impact, test stabilization is more important. However, I don't think they are mutually exclusive. For example, while waiting for your test run to come back, you can work on knocking back some warnings :-) -Joe > > Thanks, > > s'marks > > > > On 12/13/13 11:13 AM, Joe Darcy wrote: >> Hello, >> >> With JDK 9 about to get underway, I'd like to propose several source >> code and >> regression test suite improvement efforts to tackle during this release. >> >> Over the years, the JDK code base has accumulated a bit of technical >> debt in >> various areas. In JDK 8, efforts have already been underway to pay >> down that >> technical debt including: >> >> * doclint cleanup: core libs is now doclint-clean and over 1,000 of >> the doclint >> warnings in client libs have been fixed [1] >> >> * javac lint cleanup: many lint issues have been resolved [2] and a >> number of >> lint categories are configured to cause fatal errors if they are >> found when >> building the jdk repo [3] >> >> * test stabilization: numerous regression tests in the jdk repo failed >> intermittently, ran for an unnecessarily long time, or suffered from >> other flaws >> that have been corrected [4] >> >> For JDK 9, I propose we complete these initiatives for the code in >> the langtools >> and jdk repositories (then possibly extend to jaxp, jaxws, etc.): >> >> * Source code in java.* and javax.* is doclint clean for public and >> protected >> elements and the docs build is configured to fail on a doclint issue. >> The >> generated javadoc is also tidy clean. >> >> * Java sources compile cleanly under "javac -Xlint:all -Werror" and >> the build is >> configured to fail if a lint issue is introduced. >> >> * There are no chronic intermittently failing tests and clean jdk >> test runs are >> a common occurrence. >> >> Reducing C/C++ build warnings would be a worthwhile goal too, but is >> complicated >> by the number of C/C++ compilers used across different supported >> platforms. In >> addition, various structural properties of javadoc should be >> regularized ({@code >> Foo} instead of Foo, package-info.java instead of >> package.html, >> @throws instead of @exception, etc.) and the Java source code should use >> contemporary coding idioms (lambda, diamond, etc.). >> >> There are thousands of lint and doclint issues remaining, but they >> can largely >> be addressed in parallel without interfering with each other, as was >> seen in JDK >> 8. While some effort will be required to get these issues addressed >> initially, >> once the source code and tests are in a clean state, we would benefit >> from >> tooling support to prevent certain classes of errors from being >> introduced. >> >> Comments? >> >> Thanks, >> >> -Joe >> >> [1] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20doclint >> >> >> >> [2] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20in%20(lint%2C%20fixit) >> >> >> >> [3] JDK-8024643 Turn on javac lint checking in building the jdk repo >> https://bugs.openjdk.java.net/browse/JDK-8024643 >> >> JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, >> and try in >> jdk build >> https://bugs.openjdk.java.net/browse/JDK-8024603 >> >> [4] >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20fixVersion%20%3D%208%20and%20resolution%20%3D%20Fixed%20and%20labels%20%3D%20teststabilization >> >>