From mark.reinhold at oracle.com Thu Dec 1 17:33:47 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Dec 2016 09:33:47 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: <7025d324-68dd-aad7-1f2b-22b5b1836d11@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <7025d324-68dd-aad7-1f2b-22b5b1836d11@oracle.com> Message-ID: <20161201093347.898907441@eggemoggin.niobe.net> 2016/11/28 11:01:59 -0800, stefan.karlsson at oracle.com: > On 2016-11-28 18:55, joe darcy wrote: >> Last call for comments, in summary the proposal is for JDK 10 to have >> three externally visible lines of development: >> >> * master >> * hotspot > > Not an objection, but rather an observation. > > This would mean that we have two things that people will refer to as the > hotspot repository. The jdk10/hotspot top repository and the > jdk10/hotspot/hotspot repository with the hotspot code. Maybe it would > be better to stick with hs? Of course, this problem will go away when > the repository consolidation is in place, so it might be a short-lived > issue. We've named this forest "hs" for the last several releases, so continuing to name it "hs" for now to avoid confusion makes sense to me. Note also that the combined master/dev forest will be named "jdk9", not "master". (We've never had a forest named "master".) - Mark From mark.reinhold at oracle.com Thu Dec 1 17:34:37 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Dec 2016 09:34:37 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> Message-ID: <20161201093437.610550173@eggemoggin.niobe.net> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: > I need to register my concerns for SE client (the open part, not closed) > I don't think it is feasible to collapse the current lines of development > unless all our current testing done at PIT is able to be run for every push > and we are nowhere near that. Maybe even further away than we were before. So, are you saying that you want a separate "client" forest in JDK 10, as in past releases, at least for now? - Mark From joe.darcy at oracle.com Sat Dec 3 00:21:06 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 02 Dec 2016 16:21:06 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: <20161201093437.610550173@eggemoggin.niobe.net> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> Message-ID: <58420FF2.9050406@oracle.com> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: > 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >> I need to register my concerns for SE client (the open part, not closed) >> I don't think it is feasible to collapse the current lines of development >> unless all our current testing done at PIT is able to be run for every push >> and we are nowhere near that. Maybe even further away than we were before. > So, are you saying that you want a separate "client" forest in JDK 10, > as in past releases, at least for now? While continuing discussions about whether or not a separate client forest is merited, I think it would be acceptable to go forward with creating the master/dev forest and the separate forest for HotSpot, the latter named "hs". -Joe From stuart.marks at oracle.com Sat Dec 3 01:15:22 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 2 Dec 2016 17:15:22 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: <583CD4E6.2090703@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD4E6.2090703@oracle.com> Message-ID: On 11/28/16 5:07 PM, Joseph D. Darcy wrote: > On 11/28/2016 3:51 PM, John Coomes wrote: >> This would make cloning or pulling the "last known good" state more >> difficult. In jdk9, I can always clone/pull from a fixed location >> (http://.../jdk9/jdk9). With the proposal, I would have to first clone/pull >> everything, then examine the tags and sort them (which programatically means >> decoding release and build numbers, ugh), find the right tag, then pull/update >> to get the working dir in the right state. >> >> Since my clone would have all the changesets, including those beyond the "last >> known good" state, it also makes the use of 'tip' and 'default' error prone. >> If I do some archaeology and run "hg update ", then when I'm >> done, I can't go back to "last known good" with a simple "hg update default". >> I have to look at the tags again, sort them, and so on. >> >> I think it's more important that cloning or pulling the "last known good" >> state be simple, rather than promoting a build. >> >> Mercurial bookmarks might be a compromise solution - you can have a bookmark >> with a fixed name (e.g., "stable", "jdk10-stable", "last-promoted", whatever) >> that is updated each time a build is promoted. With validation from jcheck, it >> could be made reasonably safe. > > I don't object to having a convenient way to get the last known good state of > the sources, but I think the way we do this in 9, using a separate 700 MB+ Hg > forest, has too much overhead to store a relative paucity of information. > > In terms of evaluating alternatives, are there other ways you see to record this > information in Mercurial? For the "latest promoted build" case the John is concerned about, I think it should be sufficient to have a tag that's updated to point to the latest promoted build. Unlike the jdk-10+123 style tags, which are permanent, the "latest-promoted-build" tag would be updated continually. This would be a simple addition to the tagging process. Martin said: > People do "continuous testing and integration" these days. Set up your > integration pipeline so that it is always running. The pipeline > automatically promotes changesets to master when all tests pass. Easy! > Then every master changeset is equally stable to a "promoted build". There's some additional ceremony around a "promoted build" that occurs over and above the output of ordinary CI builds. In particular, such builds are published to java.net, and they're archived for the long term, whereas the CI builds are thrown away after a while. But it would be nice to have a record of the latest green CI build, in case there happens to be instability or regressions at the tip. As Joe said, having an entire separate forest for this seems wasteful, when essentially all we need is a tag. The problem with using a tag is that updating a tag in Mercurial requires a changeset. If we get (say) ten green builds per day from the CI system, that's ten tag-update changesets. I'd think that would add an excessive amount of clutter to the history. Even if we rate-limited the "latest-good-build" tagging to once a day, that's still quite a bit of clutter, and it would lag the actual latest good build by up to 24 hours. Another possibility would be to use bookmarks. A bookmark is a name that points to a changeset, like a tag. But unlike tags, bookmarks aren't versioned, and so updating them doesn't require a changeset. In addition, bookmarks have a feature that they automatically are advanced when a new changeset is committed as a child of a bookmarked changeset. This works for cases like branchy development, but it's actually counterproductive for what we're trying to do here. (The auto-advance feature would probably be useful in the sandbox, though.) Suppose for example there is a bookmark named "latest-good-build" that happens to be at the tip at the moment. I, as an individual developer, might do a pull, commit a fix, and push it. This automatically moves the "latest-good-build" to this new changeset, and this bookmark change is published to everyone along with the changeset. But if my changeset has a bug that my testing didn't uncover, then "latest-good-build" is now a lie! Only the CI system should be able to update the latest-good-build bookmark. Individuals can disable auto-advance manually when refreshing, like so: hg pull hg update latest-good-build hg bookmarks --inactive latest-good-build This seems rather easy to get wrong, though. Perhaps there's another way of dealing with bookmarks that I haven't thought of. s'marks From joe.darcy at oracle.com Sat Dec 3 01:26:06 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 02 Dec 2016 17:26:06 -0800 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <58420FF2.9050406@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> Message-ID: <58421F2E.5060109@oracle.com> On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: > On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>> I need to register my concerns for SE client (the open part, not >>> closed) >>> I don't think it is feasible to collapse the current lines of >>> development >>> unless all our current testing done at PIT is able to be run for >>> every push >>> and we are nowhere near that. Maybe even further away than we were >>> before. >> So, are you saying that you want a separate "client" forest in JDK 10, >> as in past releases, at least for now? > > While continuing discussions about whether or not a separate client > forest is merited, I think it would be acceptable to go forward with > creating the master/dev forest and the separate forest for HotSpot, > the latter named "hs". > While the number of lines of development discussion is wrapping up, before the JDK 10 forests open I think it is worthwhile to consider another question: how should the JDK 10 forests be kept up to date with changes being made in JDK 9 between the time JDK 10 opens and JDK 9 GA? The current schedule for JDK 9 has its GA on July 27, 2017. [1] For JDK 9 builds 137 through 147, the average number of fixes per builds was about 108. While the rate of bug fixes is expected to diminish as the release enter rampdown, I'd still expect many hundreds of fixes to be made in JDK 9 before it ships. In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) and the rampdown and GA of JDK 8 (March 2014 [3]), engineers were expected to be responsible for pushing their fixes both to JDK 8 and JDK 9. [4] While this approach is tractable for a relatively small number of changes, about 300 in the 12 builds of JDK 8 after JDK 9 branched off, I don't think it would scale well for the larger number of fixes expected during the overlap of JDK 9 and 10. Therefore, I think a different approach should be used this time around. Rather than protracted cherry-picking, I think changes in JDK 9 promoted builds should be merged into JDK 10, at least until JDK 9 ZBB. Comments? Thanks, -Joe [1] http://openjdk.java.net/projects/jdk9/ [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html [3] http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html [4] http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html, http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html From kevin.rushforth at oracle.com Sat Dec 3 15:57:43 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 03 Dec 2016 07:57:43 -0800 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <58421F2E.5060109@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> Message-ID: <5842EB77.1070209@oracle.com> This seems like a very good approach. We did this quite successfully for JavaFX syncing changes from 8 to 9 when JDK 9 started. It recognizes the reality that most bug fixing between now and JDK 9 ZBB will happen in the jdk9 forest. One caution is that any significant refactoring or restructuring of the source code in JDK 10 (e.g., the repo consolidation that is underway as a prototype) will cause merge challenges if such refactoring is done before JDK 9 ZBB. -- Kevin Joseph D. Darcy wrote: > On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: >> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>>> I need to register my concerns for SE client (the open part, not >>>> closed) >>>> I don't think it is feasible to collapse the current lines of >>>> development >>>> unless all our current testing done at PIT is able to be run for >>>> every push >>>> and we are nowhere near that. Maybe even further away than we were >>>> before. >>> So, are you saying that you want a separate "client" forest in JDK 10, >>> as in past releases, at least for now? >> >> While continuing discussions about whether or not a separate client >> forest is merited, I think it would be acceptable to go forward with >> creating the master/dev forest and the separate forest for HotSpot, >> the latter named "hs". >> > > While the number of lines of development discussion is wrapping up, > before the JDK 10 forests open I think it is worthwhile to consider > another question: how should the JDK 10 forests be kept up to date > with changes being made in JDK 9 between the time JDK 10 opens and JDK > 9 GA? > > The current schedule for JDK 9 has its GA on July 27, 2017. [1] For > JDK 9 builds 137 through 147, the average number of fixes per builds > was about 108. While the rate of bug fixes is expected to diminish as > the release enter rampdown, I'd still expect many hundreds of fixes to > be made in JDK 9 before it ships. > > In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) > and the rampdown and GA of JDK 8 (March 2014 [3]), engineers were > expected to be responsible for pushing their fixes both to JDK 8 and > JDK 9. [4] While this approach is tractable for a relatively small > number of changes, about 300 in the 12 builds of JDK 8 after JDK 9 > branched off, I don't think it would scale well for the larger number > of fixes expected during the overlap of JDK 9 and 10. > > Therefore, I think a different approach should be used this time > around. Rather than protracted cherry-picking, I think changes in JDK > 9 promoted builds should be merged into JDK 10, at least until JDK 9 ZBB. > > Comments? > > Thanks, > > -Joe > > [1] http://openjdk.java.net/projects/jdk9/ > > [2] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html > > [3] > http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html > > [4] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html, > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html From erik.helin at oracle.com Mon Dec 5 11:48:57 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 5 Dec 2016 12:48:57 +0100 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <58421F2E.5060109@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> Message-ID: <5f9f89ee-2f21-8cd2-20a2-597dc67dead7@oracle.com> On 12/03/2016 02:26 AM, Joseph D. Darcy wrote: > Therefore, I think a different approach should be used this time around. > Rather than protracted cherry-picking, I think changes in JDK 9 promoted > builds should be merged into JDK 10, at least until JDK 9 ZBB. > > Comments? I don't really follow how this makes backporting easier. If the code mostly stays the same in JDK 10, then backporting is relatively easy (since the patch for JDK 10 will mostly just apply to JDK 9). If this is the case, then re-merging the changes from JDK 9 into JDK 10 will also be relatively easy (again, the assumption is that the code in JDK 10 hasn't changed much). Then comes the other, hard case: I have made large, sweeping changes to the code in JDK 10 (there already such changes being worked on). In that case, backporting will be difficult: a patch for JDK 10 will *not* apply in JDK 9, the classes, files and/or methods might not even exist in JDK 9. I don't see how merging the changes made to JDK 9 into JDK 10 will help here? That merge will be very hard to get right, if not impossible (again, under the assumption that a lot of code has been changed). In more abstract terms: if the source code for JDK 10 and JDK 9 significantly diverges, will trying to merge the changes from JDK 9 into JDK 10 help? Will it even be possible? Please note that I'm not talking about changes to the version control system, such as unifying the forest. I'm trying to describe large refactorings of the source code that are independent of the kind of version control system used. Thanks, Erik > Thanks, > > -Joe > > [1] http://openjdk.java.net/projects/jdk9/ > > [2] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html > > [3] http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html > > [4] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html, > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html From david.holmes at oracle.com Mon Dec 5 12:39:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 5 Dec 2016 22:39:45 +1000 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <58421F2E.5060109@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> Message-ID: <62ea5b24-cb8e-b51f-ed56-2dcdd3806230@oracle.com> Hi Joe, On 3/12/2016 11:26 AM, Joseph D. Darcy wrote: > On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: >> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>>> I need to register my concerns for SE client (the open part, not >>>> closed) >>>> I don't think it is feasible to collapse the current lines of >>>> development >>>> unless all our current testing done at PIT is able to be run for >>>> every push >>>> and we are nowhere near that. Maybe even further away than we were >>>> before. >>> So, are you saying that you want a separate "client" forest in JDK 10, >>> as in past releases, at least for now? >> >> While continuing discussions about whether or not a separate client >> forest is merited, I think it would be acceptable to go forward with >> creating the master/dev forest and the separate forest for HotSpot, >> the latter named "hs". >> > > While the number of lines of development discussion is wrapping up, > before the JDK 10 forests open I think it is worthwhile to consider > another question: how should the JDK 10 forests be kept up to date with > changes being made in JDK 9 between the time JDK 10 opens and JDK 9 GA? > > The current schedule for JDK 9 has its GA on July 27, 2017. [1] For JDK > 9 builds 137 through 147, the average number of fixes per builds was > about 108. While the rate of bug fixes is expected to diminish as the > release enter rampdown, I'd still expect many hundreds of fixes to be > made in JDK 9 before it ships. > > In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) and > the rampdown and GA of JDK 8 (March 2014 [3]), engineers were expected > to be responsible for pushing their fixes both to JDK 8 and JDK 9. [4] > While this approach is tractable for a relatively small number of > changes, about 300 in the 12 builds of JDK 8 after JDK 9 branched off, I > don't think it would scale well for the larger number of fixes expected > during the overlap of JDK 9 and 10. > > Therefore, I think a different approach should be used this time around. > Rather than protracted cherry-picking, I think changes in JDK 9 promoted > builds should be merged into JDK 10, at least until JDK 9 ZBB. > > Comments? It obviously depends on the number of fixes going into 9 and the number of significant changes that go early into 10. There are a number of refactorings and cleanups that are slated for early in 10 - at least on the hotspot side - which may make straight merging by a "generic" gatekeeper somewhat challenging. But as ZBB is only 8 weeks away this may be short enough (given the Xmas break etc) to make this manageable. I think it makes sense to try for a scheme that minimises the workload on the individual developers, and we'll just have to see how far we get before things become unmanageable. We could also chose to delay significantly disruptive changes until after ZBB. Cheers, David > Thanks, > > -Joe > > [1] http://openjdk.java.net/projects/jdk9/ > > [2] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html > > [3] http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html > > [4] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html, > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html From joe.darcy at oracle.com Mon Dec 5 21:18:55 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 5 Dec 2016 13:18:55 -0800 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <5f9f89ee-2f21-8cd2-20a2-597dc67dead7@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> <5f9f89ee-2f21-8cd2-20a2-597dc67dead7@oracle.com> Message-ID: <1fcff4e4-c92d-7318-f78e-54d6e948e3c3@oracle.com> On 12/5/2016 3:48 AM, Erik Helin wrote: > On 12/03/2016 02:26 AM, Joseph D. Darcy wrote: >> Therefore, I think a different approach should be used this time around. >> Rather than protracted cherry-picking, I think changes in JDK 9 promoted >> builds should be merged into JDK 10, at least until JDK 9 ZBB. >> >> Comments? > > I don't really follow how this makes backporting easier. To clarify, I'm proposing a forward-port model for at least a portion of the 9 and 10 overlap. A developer doing work that needs to get into 9 would do the work in 9 first and then a periodic process would bulk sync the 9 changes into 10. HTH, -Joe From joe.darcy at oracle.com Tue Dec 6 05:23:47 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 5 Dec 2016 21:23:47 -0800 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <62ea5b24-cb8e-b51f-ed56-2dcdd3806230@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> <62ea5b24-cb8e-b51f-ed56-2dcdd3806230@oracle.com> Message-ID: <0cb94112-8609-d8a1-0d51-e09bbac55b16@oracle.com> Hi David, On 12/5/2016 4:39 AM, David Holmes wrote: > Hi Joe, > > On 3/12/2016 11:26 AM, Joseph D. Darcy wrote: >> On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: >>> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >>>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>>>> I need to register my concerns for SE client (the open part, not >>>>> closed) >>>>> I don't think it is feasible to collapse the current lines of >>>>> development >>>>> unless all our current testing done at PIT is able to be run for >>>>> every push >>>>> and we are nowhere near that. Maybe even further away than we were >>>>> before. >>>> So, are you saying that you want a separate "client" forest in JDK 10, >>>> as in past releases, at least for now? >>> >>> While continuing discussions about whether or not a separate client >>> forest is merited, I think it would be acceptable to go forward with >>> creating the master/dev forest and the separate forest for HotSpot, >>> the latter named "hs". >>> >> >> While the number of lines of development discussion is wrapping up, >> before the JDK 10 forests open I think it is worthwhile to consider >> another question: how should the JDK 10 forests be kept up to date with >> changes being made in JDK 9 between the time JDK 10 opens and JDK 9 GA? >> >> The current schedule for JDK 9 has its GA on July 27, 2017. [1] For JDK >> 9 builds 137 through 147, the average number of fixes per builds was >> about 108. While the rate of bug fixes is expected to diminish as the >> release enter rampdown, I'd still expect many hundreds of fixes to be >> made in JDK 9 before it ships. >> >> In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) and >> the rampdown and GA of JDK 8 (March 2014 [3]), engineers were expected >> to be responsible for pushing their fixes both to JDK 8 and JDK 9. [4] >> While this approach is tractable for a relatively small number of >> changes, about 300 in the 12 builds of JDK 8 after JDK 9 branched off, I >> don't think it would scale well for the larger number of fixes expected >> during the overlap of JDK 9 and 10. >> >> Therefore, I think a different approach should be used this time around. >> Rather than protracted cherry-picking, I think changes in JDK 9 promoted >> builds should be merged into JDK 10, at least until JDK 9 ZBB. >> >> Comments? > > It obviously depends on the number of fixes going into 9 and the > number of significant changes that go early into 10. There are a > number of refactorings and cleanups that are slated for early in 10 - > at least on the hotspot side - which may make straight merging by a > "generic" gatekeeper somewhat challenging. But as ZBB is only 8 weeks > away this may be short enough (given the Xmas break etc) to make this > manageable. > > I think it makes sense to try for a scheme that minimises the workload > on the individual developers, and we'll just have to see how far we > get before things become unmanageable. We could also chose to delay > significantly disruptive changes until after ZBB. On a related note, I was thinking disruptive changes might initially be better done in a sandbox then in 10 mainline for a while to ease keeping 10 up to date with changes still occurring in 9. Given the nontrivial amount of work in 9 (and the urgency of getting it finished!), at least for a while I think supporting the ability of getting the remaining 9 work done should take priority over fostering disruptive changes in 10. Cheers, -Joe From david.holmes at oracle.com Tue Dec 6 06:03:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Dec 2016 16:03:49 +1000 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <0cb94112-8609-d8a1-0d51-e09bbac55b16@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> <62ea5b24-cb8e-b51f-ed56-2dcdd3806230@oracle.com> <0cb94112-8609-d8a1-0d51-e09bbac55b16@oracle.com> Message-ID: Hi Joe, On 6/12/2016 3:23 PM, joe darcy wrote: > Hi David, > > On 12/5/2016 4:39 AM, David Holmes wrote: >> Hi Joe, >> >> On 3/12/2016 11:26 AM, Joseph D. Darcy wrote: >>> On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: >>>> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >>>>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>>>>> I need to register my concerns for SE client (the open part, not >>>>>> closed) >>>>>> I don't think it is feasible to collapse the current lines of >>>>>> development >>>>>> unless all our current testing done at PIT is able to be run for >>>>>> every push >>>>>> and we are nowhere near that. Maybe even further away than we were >>>>>> before. >>>>> So, are you saying that you want a separate "client" forest in JDK 10, >>>>> as in past releases, at least for now? >>>> >>>> While continuing discussions about whether or not a separate client >>>> forest is merited, I think it would be acceptable to go forward with >>>> creating the master/dev forest and the separate forest for HotSpot, >>>> the latter named "hs". >>>> >>> >>> While the number of lines of development discussion is wrapping up, >>> before the JDK 10 forests open I think it is worthwhile to consider >>> another question: how should the JDK 10 forests be kept up to date with >>> changes being made in JDK 9 between the time JDK 10 opens and JDK 9 GA? >>> >>> The current schedule for JDK 9 has its GA on July 27, 2017. [1] For JDK >>> 9 builds 137 through 147, the average number of fixes per builds was >>> about 108. While the rate of bug fixes is expected to diminish as the >>> release enter rampdown, I'd still expect many hundreds of fixes to be >>> made in JDK 9 before it ships. >>> >>> In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) and >>> the rampdown and GA of JDK 8 (March 2014 [3]), engineers were expected >>> to be responsible for pushing their fixes both to JDK 8 and JDK 9. [4] >>> While this approach is tractable for a relatively small number of >>> changes, about 300 in the 12 builds of JDK 8 after JDK 9 branched off, I >>> don't think it would scale well for the larger number of fixes expected >>> during the overlap of JDK 9 and 10. >>> >>> Therefore, I think a different approach should be used this time around. >>> Rather than protracted cherry-picking, I think changes in JDK 9 promoted >>> builds should be merged into JDK 10, at least until JDK 9 ZBB. >>> >>> Comments? >> >> It obviously depends on the number of fixes going into 9 and the >> number of significant changes that go early into 10. There are a >> number of refactorings and cleanups that are slated for early in 10 - >> at least on the hotspot side - which may make straight merging by a >> "generic" gatekeeper somewhat challenging. But as ZBB is only 8 weeks >> away this may be short enough (given the Xmas break etc) to make this >> manageable. >> >> I think it makes sense to try for a scheme that minimises the workload >> on the individual developers, and we'll just have to see how far we >> get before things become unmanageable. We could also chose to delay >> significantly disruptive changes until after ZBB. > > On a related note, I was thinking disruptive changes might initially be > better done in a sandbox then in 10 mainline for a while to ease keeping > 10 up to date with changes still occurring in 9. That will need some coordination and agreement on what constitutes "disruptive". A lot of people are waiting eagerly for the 10 repo to open so they can start clearing the decks. :) Particularly in relation to some cleanup RFEs in hotspot. David ----- > Given the nontrivial amount of work in 9 (and the urgency of getting it > finished!), at least for a while I think supporting the ability of > getting the remaining 9 work done should take priority over fostering > disruptive changes in 10. > > Cheers, > > -Joe From thomas.stuefe at gmail.com Tue Dec 6 08:03:20 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 Dec 2016 09:03:20 +0100 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> <62ea5b24-cb8e-b51f-ed56-2dcdd3806230@oracle.com> <0cb94112-8609-d8a1-0d51-e09bbac55b16@oracle.com> Message-ID: On Tue, Dec 6, 2016 at 7:03 AM, David Holmes wrote: > Hi Joe, > > > On 6/12/2016 3:23 PM, joe darcy wrote: > >> Hi David, >> >> On 12/5/2016 4:39 AM, David Holmes wrote: >> >>> Hi Joe, >>> >>> On 3/12/2016 11:26 AM, Joseph D. Darcy wrote: >>> >>>> On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: >>>> >>>>> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >>>>> >>>>>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>>>>> >>>>>>> I need to register my concerns for SE client (the open part, not >>>>>>> closed) >>>>>>> I don't think it is feasible to collapse the current lines of >>>>>>> development >>>>>>> unless all our current testing done at PIT is able to be run for >>>>>>> every push >>>>>>> and we are nowhere near that. Maybe even further away than we were >>>>>>> before. >>>>>>> >>>>>> So, are you saying that you want a separate "client" forest in JDK 10, >>>>>> as in past releases, at least for now? >>>>>> >>>>> >>>>> While continuing discussions about whether or not a separate client >>>>> forest is merited, I think it would be acceptable to go forward with >>>>> creating the master/dev forest and the separate forest for HotSpot, >>>>> the latter named "hs". >>>>> >>>>> >>>> While the number of lines of development discussion is wrapping up, >>>> before the JDK 10 forests open I think it is worthwhile to consider >>>> another question: how should the JDK 10 forests be kept up to date with >>>> changes being made in JDK 9 between the time JDK 10 opens and JDK 9 GA? >>>> >>>> The current schedule for JDK 9 has its GA on July 27, 2017. [1] For JDK >>>> 9 builds 137 through 147, the average number of fixes per builds was >>>> about 108. While the rate of bug fixes is expected to diminish as the >>>> release enter rampdown, I'd still expect many hundreds of fixes to be >>>> made in JDK 9 before it ships. >>>> >>>> In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) and >>>> the rampdown and GA of JDK 8 (March 2014 [3]), engineers were expected >>>> to be responsible for pushing their fixes both to JDK 8 and JDK 9. [4] >>>> While this approach is tractable for a relatively small number of >>>> changes, about 300 in the 12 builds of JDK 8 after JDK 9 branched off, I >>>> don't think it would scale well for the larger number of fixes expected >>>> during the overlap of JDK 9 and 10. >>>> >>>> Therefore, I think a different approach should be used this time around. >>>> Rather than protracted cherry-picking, I think changes in JDK 9 promoted >>>> builds should be merged into JDK 10, at least until JDK 9 ZBB. >>>> >>>> Comments? >>>> >>> >>> It obviously depends on the number of fixes going into 9 and the >>> number of significant changes that go early into 10. There are a >>> number of refactorings and cleanups that are slated for early in 10 - >>> at least on the hotspot side - which may make straight merging by a >>> "generic" gatekeeper somewhat challenging. But as ZBB is only 8 weeks >>> away this may be short enough (given the Xmas break etc) to make this >>> manageable. >>> >>> I think it makes sense to try for a scheme that minimises the workload >>> on the individual developers, and we'll just have to see how far we >>> get before things become unmanageable. We could also chose to delay >>> significantly disruptive changes until after ZBB. >>> >> >> On a related note, I was thinking disruptive changes might initially be >> better done in a sandbox then in 10 mainline for a while to ease keeping >> 10 up to date with changes still occurring in 9. >> > > That will need some coordination and agreement on what constitutes > "disruptive". A lot of people are waiting eagerly for the 10 repo to open > so they can start clearing the decks. :) Particularly in relation to some > cleanup RFEs in hotspot. > > I also think it would be difficult to decide what is "disruptive" and what is allowed in the main code line in a fair way, because this is quite subjective. Unless you count changed lines of code or similar. We had a similar situation the past two months, where the decision if a change is a bug or an enhancement felt sometimes a bit arbitrary. But it did not matter much, because the JDK10 repository was right around the corner. But if we have to hold back larger changes until July 2017, this would mean quite a backlog of cleanup changes. I understand the motivation behind it, I am just not very happy about it. Kind Regards, Thomas > David > ----- > > Given the nontrivial amount of work in 9 (and the urgency of getting it >> finished!), at least for a while I think supporting the ability of >> getting the remaining 9 work done should take priority over fostering >> disruptive changes in 10. >> >> Cheers, >> >> -Joe >> > From joe.darcy at oracle.com Tue Dec 13 16:39:43 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 13 Dec 2016 08:39:43 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> Message-ID: Hello, An update, after some off-list discussions I agree it is reasonable to initially maintain a client forest. However, the client forest may be retired later in JDK 10 if the testing situation allows. Therefore, the proposed lines of development are now: * master - jdk10/jdk10 * hotspot - jdk10/hs * sandbox - jdk10/sandbox * client - jdk10/client Cheers, -Joe On 11/29/2016 2:02 PM, Phil Race wrote: > Hi Joe, > > I need to register my concerns for SE client (the open part, not closed) > I don't think it is feasible to collapse the current lines of development > unless all our current testing done at PIT is able to be run for every > push > and we are nowhere near that. Maybe even further away than we were > before. > > -phil. > > > > On 11/28/2016 09:55 AM, joe darcy wrote: >> Hello again, >> >> Last call for comments, in summary the proposal is for JDK 10 to have >> three externally visible lines of development: >> >> * master >> * hotspot >> * sandbox >> >> If there are no objections by Nov. 30, I think we should go ahead >> with this arrangement. >> >> Thanks, >> >> -Joe >> >> >> On 11/18/2016 8:33 AM, joe darcy wrote: >>> Hello, >>> >>> On 11/18/2016 5:50 AM, Aleksey Shipilev wrote: >>>> Hi, >>>> >>>> It is very exciting to see the JDK 10 mailing list! >>>> >>>> When can we expect open forests (or maybe a monorepo that was >>>> discussed >>>> at jdk9-dev some time ago [1]) for JDK 10? :) >>>> >>>> Thanks, >>>> -Aleksey >>>> >>>> [1] http://openjdk.java.net/jeps/296 >>> >>> And thus will commence the first thread in jdk10-dev, how many lines >>> of development where "line is development" means either a forest or >>> a monorepo. >>> >>> For a few reasons including not holding up the start of JDK 10 >>> development for further discussion about and administrative >>> advancement of JEP 296 and to give more time to work on >>> internal-only details of the repo consolidation (such as how the >>> various closed repos are handled), the JDK 10 lines of development >>> won't start out as monorepos. They will at least initially use the >>> existing multi-repo structure as in JDK 9. However, we'll return to >>> JEP 296 later in the release. >>> >>> Regardless of many repos used for a line of the development, there >>> is a larger question of how many lines of development to have. For >>> JDK 10 I propose three lines of development: >>> >>> * A master forest, serving the roles master and dev play today in 9. >>> >>> With a few exceptions, in JDK 9 master was just time-delayed copy of >>> dev so we can implement recording the information about which set >>> of sources correspond to a promoted build without using a whole >>> other forest. >>> >>> Rather than using a separate line of development for client-libs >>> work as in 9, I think this should be done in the same line of >>> development as all other libs work in 10. >>> >>> * Single HotSpot forest. >>> >>> Over of the course of JDK 9, the HotSpot team went from using >>> multiple forests for their work to using a single one. >>> >>> * Sandbox >>> >>> The JDK 9 sandbox (http://hg.openjdk.java.net/jdk9/sandbox/) allows >>> collaboration and publication of sources of small projects outside >>> the main line of development. This ability should continue in JDK 10. >>> >>> Comments? >>> >>> Thanks, >>> >>> -Joe >> > From martinrb at google.com Wed Dec 14 19:22:33 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 Dec 2016 11:22:33 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: <583CD0D8.3000105@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD0D8.3000105@oracle.com> Message-ID: On Mon, Nov 28, 2016 at 4:50 PM, Joseph D. Darcy wrote: > On 11/28/2016 3:30 PM, Martin Buchholz wrote: > > As an aside, for JDK 10 I'd also like to see promoted builds on a more >> frequent schedule than once a week. >> > > People do "continuous testing and integration" these days. Set up your > integration pipeline so that it is always running. The pipeline > automatically promotes changesets to master when all tests pass. Easy! > Then every master changeset is equally stable to a "promoted build". > > > One of the internal systems mentioned above is a CI system that run > regression tests after a change is pushed. The approximate integration > model is then to promote known-good states of sources as vetted by the CI > system. > > If problems are fixed soon after they are identified, then a post-push > system gives good results with avoiding the need more complexity on the > front end to manage a series of in-flight patches. > A CI system available to every committer that would guarantee no regressions would be awesome! I fundamentally do not believe in post-submit testing. I want to be protected from my own mistakes and those of others. Google has also moved towards doing more presubmit testing. For large low-level infrastructure projects like openjdk, I envision different layers of testing. The first layer would run e.g. the jtreg and jck tests, perhaps on a distributed test farm. A second layer might run publicly available java test suites that would be too expensive to run in a first layer. Promotion to a "golden master" might be dependent on passing tests in the second layer. Of course, that would be a serious investment in testing/quality. From yasuenag at gmail.com Wed Dec 14 23:54:03 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 15 Dec 2016 08:54:03 +0900 Subject: Repository? -- How many lines of development? In-Reply-To: References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD0D8.3000105@oracle.com> Message-ID: Hi, 2016/12/15 4:23 "Martin Buchholz" : On Mon, Nov 28, 2016 at 4:50 PM, Joseph D. Darcy wrote: > On 11/28/2016 3:30 PM, Martin Buchholz wrote: > > As an aside, for JDK 10 I'd also like to see promoted builds on a more >> frequent schedule than once a week. >> > > People do "continuous testing and integration" these days. Set up your > integration pipeline so that it is always running. The pipeline > automatically promotes changesets to master when all tests pass. Easy! > Then every master changeset is equally stable to a "promoted build". > > > One of the internal systems mentioned above is a CI system that run > regression tests after a change is pushed. The approximate integration > model is then to promote known-good states of sources as vetted by the CI > system. > > If problems are fixed soon after they are identified, then a post-push > system gives good results with avoiding the need more complexity on the > front end to manage a series of in-flight patches. > A CI system available to every committer that would guarantee no regressions would be awesome! I'm a reviewer of jdk 9 project (ysuenaga), but I'm not am employee at Oracle. So I cannot access CI system in Oracle. Can I access it since jdk 10? Thanks, Yasumasa I fundamentally do not believe in post-submit testing. I want to be protected from my own mistakes and those of others. Google has also moved towards doing more presubmit testing. For large low-level infrastructure projects like openjdk, I envision different layers of testing. The first layer would run e.g. the jtreg and jck tests, perhaps on a distributed test farm. A second layer might run publicly available java test suites that would be too expensive to run in a first layer. Promotion to a "golden master" might be dependent on passing tests in the second layer. Of course, that would be a serious investment in testing/quality. From joe.darcy at oracle.com Thu Dec 15 01:05:52 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 14 Dec 2016 17:05:52 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD0D8.3000105@oracle.com> Message-ID: <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com> On 12/14/2016 11:22 AM, Martin Buchholz wrote: > > > On Mon, Nov 28, 2016 at 4:50 PM, Joseph D. Darcy > wrote: > > On 11/28/2016 3:30 PM, Martin Buchholz wrote: >> >> As an aside, for JDK 10 I'd also like to see promoted builds >> on a more frequent schedule than once a week. >> >> >> People do "continuous testing and integration" these days. Set >> up your integration pipeline so that it is always running. The >> pipeline automatically promotes changesets to master when all >> tests pass. Easy! Then every master changeset is equally stable >> to a "promoted build". > > One of the internal systems mentioned above is a CI system that > run regression tests after a change is pushed. The approximate > integration model is then to promote known-good states of sources > as vetted by the CI system. > > If problems are fixed soon after they are identified, then a > post-push system gives good results with avoiding the need more > complexity on the front end to manage a series of in-flight patches. > > > A CI system available to every committer that would guarantee no > regressions would be awesome! > > I fundamentally do not believe in post-submit testing. I want to be > protected from my own mistakes and those of others. Google has also > moved towards doing more presubmit testing. > > For large low-level infrastructure projects like openjdk, I envision > different layers of testing. The first layer would run e.g. the jtreg > and jck tests, perhaps on a distributed test farm. A second layer > might run publicly available java test suites that would be too > expensive to run in a first layer. Promotion to a "golden master" > might be dependent on passing tests in the second layer. Of course, > that would be a serious investment in testing/quality. The tiered testing efforts made earlier in JDK 9 [1] are necessary preconditions for a JDK-wide pre-push/pre-submit system. In particular, if you don't have a a set of meaningful tests that runs quickly enough and passes reliably enough then a pre-push system can cause more harm than good in introducing bottlenecks and causing changes to be spuriously rejected, say by an existing intermittent failure unrelated to the change. If the testing preconditions are met, there is still the small matter of the submission system managing the queues, perhaps some with kind of scoreboarding algorithm (https://en.wikipedia.org/wiki/Scoreboarding) to reduce latencies, etc. In the meantime, I think post-push testing and prompt fixing is a fine approximation to pre-push testing and something we can (continue to) do now. Independent of pre-push or post-push, the most important aspect of this is making sure everyone treats build and test failures as urgent problems that need to be addressed quickly. Cheers, -Joe [1] "Proposed new policies for JDK 9 regression tests: tiered testing, intermittent failures, and randomness," http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html ?Proposed new policies for JDK 9 regression tests: tiered testing, intermittent failures, and randomness,? http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002164.html ?Test policy follow-up, third testing tier,? http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html From martinrb at google.com Thu Dec 15 04:25:43 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 Dec 2016 20:25:43 -0800 Subject: Repository? -- How many lines of development? In-Reply-To: <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD0D8.3000105@oracle.com> <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com> Message-ID: On Wed, Dec 14, 2016 at 5:05 PM, joe darcy wrote: > > The tiered testing efforts made earlier in JDK 9 [1] are necessary > preconditions for a JDK-wide pre-push/pre-submit system. In particular, if > you don't have a a set of meaningful tests that runs quickly enough and > passes reliably enough then a pre-push system can cause more harm than good > in introducing bottlenecks and causing changes to be spuriously rejected, > say by an existing intermittent failure unrelated to the change. > It's a hard problem, but I think with sufficient effort presubmit can work well. Testing is embarrassingly parallel in principle so with enough hardware (or one of those "clouds" everyone is selling these days) one should be able to run arbitrarily many tests. No one seems to deal well with flaky tests, but flakiness can be measured, and a failing test can be rerun arbitrarily, so deflaking should be automatable. At Google we are starting to experiment with running jtreg tests with massive parallelism. Automation, presubmit testing and never-ever-broken master remain my goals for any software project. From weijun.wang at oracle.com Thu Dec 15 04:32:59 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 15 Dec 2016 12:32:59 +0800 Subject: Repository? -- How many lines of development? In-Reply-To: References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD0D8.3000105@oracle.com> <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com> Message-ID: IMHO never-ever-broken master is the main obstacle here, the auto-rerun feature you suggested is nice, but I am also in favor of a could-fail-do-not-panic keyword. --Max > On Dec 15, 2016, at 12:25 PM, Martin Buchholz wrote: > > Automation, presubmit testing and never-ever-broken master remain my goals > for any software project. From goetz.lindenmaier at sap.com Thu Dec 15 07:18:25 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Dec 2016 07:18:25 +0000 Subject: Repository? -- How many lines of development? In-Reply-To: References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD0D8.3000105@oracle.com> <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com> Message-ID: <0b3d06485bc4458c829d22982fa59d02@DEROTE13DE08.global.corp.sap> > well. Testing is embarrassingly parallel in principle so with enough > hardware (or one of those "clouds" everyone is selling these days) one > should be able to run arbitrarily many tests. No one seems to deal well Hmm, is there a cloud containing all the different platforms? solarisx86_64? aixppc64? linuxs390x? linuxarm32? I also think pre-submit testing is really helpful, but supplying the compute power on all these platforms to do this to an extend that you don't need any further testing is out of scope. Best regards, Goetz. > -----Original Message----- > From: jdk10-dev [mailto:jdk10-dev-bounces at openjdk.java.net] On Behalf Of > Martin Buchholz > Sent: Thursday, December 15, 2016 5:26 AM > To: joe darcy > Cc: jdk10-dev at openjdk.java.net; quality-discuss at openjdk.java.net > Subject: Re: Repository? -- How many lines of development? > > On Wed, Dec 14, 2016 at 5:05 PM, joe darcy wrote: > > > > > The tiered testing efforts made earlier in JDK 9 [1] are necessary > > preconditions for a JDK-wide pre-push/pre-submit system. In particular, if > > you don't have a a set of meaningful tests that runs quickly enough and > > passes reliably enough then a pre-push system can cause more harm than > good > > in introducing bottlenecks and causing changes to be spuriously rejected, > > say by an existing intermittent failure unrelated to the change. > > > > It's a hard problem, but I think with sufficient effort presubmit can work > well. Testing is embarrassingly parallel in principle so with enough > hardware (or one of those "clouds" everyone is selling these days) one > should be able to run arbitrarily many tests. No one seems to deal well > with flaky tests, but flakiness can be measured, and a failing test can be > rerun arbitrarily, so deflaking should be automatable. > > At Google we are starting to experiment with running jtreg tests with > massive parallelism. > > Automation, presubmit testing and never-ever-broken master remain my > goals > for any software project. From martijnverburg at gmail.com Thu Dec 15 09:10:12 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 15 Dec 2016 09:10:12 +0000 Subject: Repository? -- How many lines of development? In-Reply-To: <0b3d06485bc4458c829d22982fa59d02@DEROTE13DE08.global.corp.sap> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com> <583CAABF.6000102@oracle.com> <583CD0D8.3000105@oracle.com> <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com> <0b3d06485bc4458c829d22982fa59d02@DEROTE13DE08.global.corp.sap> Message-ID: Hi Goetz, A few FOSDEM's ago a group of us came up with a *optional* (i.e. No one should be forced to it) patch pipeline architecture where each vendor who had specific platforms could pull patches from a queue, build them on their specialised platform and return a result. This of course would require a little bit of common infrastructure which the London Java Community (as a non-profit entity) was willing to own/host on behalf of OpenJDK. At the time there wasn't unanimous support for this idea (I imagine for cost/resource reasons) from the major vendors involved in OpenJDK, but if folks think this is a good time to revisit the discussion then perhaps we could have a session on this at the upcoming 2017 FOSDEM. Cheers, Martijn On 15 December 2016 at 07:18, Lindenmaier, Goetz wrote: > > well. Testing is embarrassingly parallel in principle so with enough > > hardware (or one of those "clouds" everyone is selling these days) one > > should be able to run arbitrarily many tests. No one seems to deal well > > Hmm, is there a cloud containing all the different platforms? > solarisx86_64? aixppc64? linuxs390x? linuxarm32? > I also think pre-submit testing is really helpful, but supplying the > compute power on all these platforms to do this to an extend > that you don't need any further testing is out of scope. > > Best regards, > Goetz. > > > > > > > -----Original Message----- > > From: jdk10-dev [mailto:jdk10-dev-bounces at openjdk.java.net] On Behalf Of > > Martin Buchholz > > Sent: Thursday, December 15, 2016 5:26 AM > > To: joe darcy > > Cc: jdk10-dev at openjdk.java.net; quality-discuss at openjdk.java.net > > Subject: Re: Repository? -- How many lines of development? > > > > On Wed, Dec 14, 2016 at 5:05 PM, joe darcy wrote: > > > > > > > > The tiered testing efforts made earlier in JDK 9 [1] are necessary > > > preconditions for a JDK-wide pre-push/pre-submit system. In > particular, if > > > you don't have a a set of meaningful tests that runs quickly enough and > > > passes reliably enough then a pre-push system can cause more harm than > > good > > > in introducing bottlenecks and causing changes to be spuriously > rejected, > > > say by an existing intermittent failure unrelated to the change. > > > > > > > It's a hard problem, but I think with sufficient effort presubmit can > work > > well. Testing is embarrassingly parallel in principle so with enough > > hardware (or one of those "clouds" everyone is selling these days) one > > should be able to run arbitrarily many tests. No one seems to deal well > > with flaky tests, but flakiness can be measured, and a failing test can > be > > rerun arbitrarily, so deflaking should be automatable. > > > > At Google we are starting to experiment with running jtreg tests with > > massive parallelism. > > > > Automation, presubmit testing and never-ever-broken master remain my > > goals > > for any software project. > From joe.darcy at oracle.com Tue Dec 20 23:54:18 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 20 Dec 2016 15:54:18 -0800 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <58421F2E.5060109@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> Message-ID: <47b08c87-8b9d-ac86-83c2-28726daec93f@oracle.com> Hello, Returning to this topic, after additional consideration, I still think we should start JDK 10 by hg pull'ing changes in from JDK 9. In other words, adopt a forward-port rather than back-port policy, at least for the time being. Under this model, engineers with a fix that had to go into both JDK 9 and JDK 10 would just push the fix into 9 and a separate periodic process would sync the changes into 10. Comments? Thanks, -Joe On 12/2/2016 5:26 PM, Joseph D. Darcy wrote: > On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: >> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>>> I need to register my concerns for SE client (the open part, not >>>> closed) >>>> I don't think it is feasible to collapse the current lines of >>>> development >>>> unless all our current testing done at PIT is able to be run for >>>> every push >>>> and we are nowhere near that. Maybe even further away than we were >>>> before. >>> So, are you saying that you want a separate "client" forest in JDK 10, >>> as in past releases, at least for now? >> >> While continuing discussions about whether or not a separate client >> forest is merited, I think it would be acceptable to go forward with >> creating the master/dev forest and the separate forest for HotSpot, >> the latter named "hs". >> > > While the number of lines of development discussion is wrapping up, > before the JDK 10 forests open I think it is worthwhile to consider > another question: how should the JDK 10 forests be kept up to date > with changes being made in JDK 9 between the time JDK 10 opens and JDK > 9 GA? > > The current schedule for JDK 9 has its GA on July 27, 2017. [1] For > JDK 9 builds 137 through 147, the average number of fixes per builds > was about 108. While the rate of bug fixes is expected to diminish as > the release enter rampdown, I'd still expect many hundreds of fixes to > be made in JDK 9 before it ships. > > In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) > and the rampdown and GA of JDK 8 (March 2014 [3]), engineers were > expected to be responsible for pushing their fixes both to JDK 8 and > JDK 9. [4] While this approach is tractable for a relatively small > number of changes, about 300 in the 12 builds of JDK 8 after JDK 9 > branched off, I don't think it would scale well for the larger number > of fixes expected during the overlap of JDK 9 and 10. > > Therefore, I think a different approach should be used this time > around. Rather than protracted cherry-picking, I think changes in JDK > 9 promoted builds should be merged into JDK 10, at least until JDK 9 ZBB. > > Comments? > > Thanks, > > -Joe > > [1] http://openjdk.java.net/projects/jdk9/ > > [2] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html > > [3] > http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html > > [4] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html, > http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html From aph at redhat.com Wed Dec 21 08:31:56 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Dec 2016 08:31:56 +0000 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <47b08c87-8b9d-ac86-83c2-28726daec93f@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> <47b08c87-8b9d-ac86-83c2-28726daec93f@oracle.com> Message-ID: <58941ef8-25b7-bb51-2be0-582667923a2e@redhat.com> On 20/12/16 23:54, joe darcy wrote: > Returning to this topic, after additional consideration, I still think > we should start JDK 10 by hg pull'ing changes in from JDK 9. In other > words, adopt a forward-port rather than back-port policy, at least for > the time being. > > Under this model, engineers with a fix that had to go into both JDK 9 > and JDK 10 would just push the fix into 9 and a separate periodic > process would sync the changes into 10. I think that sounds best. Andrew. From ivan.gerasimov at oracle.com Wed Dec 21 08:41:35 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 21 Dec 2016 11:41:35 +0300 Subject: Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA? In-Reply-To: <47b08c87-8b9d-ac86-83c2-28726daec93f@oracle.com> References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com> <11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com> <633ced12-ded6-29b4-e367-a26de70012b6@oracle.com> <20161201093437.610550173@eggemoggin.niobe.net> <58420FF2.9050406@oracle.com> <58421F2E.5060109@oracle.com> <47b08c87-8b9d-ac86-83c2-28726daec93f@oracle.com> Message-ID: <72a5640a-1c51-dc5f-b500-84ac150798f7@oracle.com> On 21.12.2016 2:54, joe darcy wrote: > Hello, > > Returning to this topic, after additional consideration, I still think > we should start JDK 10 by hg pull'ing changes in from JDK 9. In other > words, adopt a forward-port rather than back-port policy, at least for > the time being. > > Under this model, engineers with a fix that had to go into both JDK 9 > and JDK 10 would just push the fix into 9 and a separate periodic > process would sync the changes into 10. > Out of curiosity, if a bulk forward-port causes a conflict or a build failure or a test failure or something else, whose responsibility would be to deal with it? In the backport model, this is the backporter who's checking how the change applies. With the periodic syncing process, it's not that clear. With kind regards, Ivan > Comments? > > Thanks, > > -Joe > > > On 12/2/2016 5:26 PM, Joseph D. Darcy wrote: >> On 12/2/2016 4:21 PM, Joseph D. Darcy wrote: >>> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote: >>>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com: >>>>> I need to register my concerns for SE client (the open part, not >>>>> closed) >>>>> I don't think it is feasible to collapse the current lines of >>>>> development >>>>> unless all our current testing done at PIT is able to be run for >>>>> every push >>>>> and we are nowhere near that. Maybe even further away than we were >>>>> before. >>>> So, are you saying that you want a separate "client" forest in JDK 10, >>>> as in past releases, at least for now? >>> >>> While continuing discussions about whether or not a separate client >>> forest is merited, I think it would be acceptable to go forward with >>> creating the master/dev forest and the separate forest for HotSpot, >>> the latter named "hs". >>> >> >> While the number of lines of development discussion is wrapping up, >> before the JDK 10 forests open I think it is worthwhile to consider >> another question: how should the JDK 10 forests be kept up to date >> with changes being made in JDK 9 between the time JDK 10 opens and >> JDK 9 GA? >> >> The current schedule for JDK 9 has its GA on July 27, 2017. [1] For >> JDK 9 builds 137 through 147, the average number of fixes per builds >> was about 108. While the rate of bug fixes is expected to diminish as >> the release enter rampdown, I'd still expect many hundreds of fixes >> to be made in JDK 9 before it ships. >> >> In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) >> and the rampdown and GA of JDK 8 (March 2014 [3]), engineers were >> expected to be responsible for pushing their fixes both to JDK 8 and >> JDK 9. [4] While this approach is tractable for a relatively small >> number of changes, about 300 in the 12 builds of JDK 8 after JDK 9 >> branched off, I don't think it would scale well for the larger number >> of fixes expected during the overlap of JDK 9 and 10. >> >> Therefore, I think a different approach should be used this time >> around. Rather than protracted cherry-picking, I think changes in JDK >> 9 promoted builds should be merged into JDK 10, at least until JDK 9 >> ZBB. >> >> Comments? >> >> Thanks, >> >> -Joe >> >> [1] http://openjdk.java.net/projects/jdk9/ >> >> [2] >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html >> >> [3] >> http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html >> >> [4] >> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html, >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html >> > >