From rob.mckenna at oracle.com Thu Feb 1 17:50:02 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 1 Feb 2018 17:50:02 +0000 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: References: <20180112151935.GC4779@vimes> <20180129175802.GA4886@vimes> <2898d47a-5916-d11e-af24-1e4dca34da8b@oracle.com>

Message-ID: <4C41F4E4-9E30-4D7C-B930-CBAE324CD78D@oracle.com> We were just discussing this yesterday. Its a placeholder. I?m planning on replacing it with a more appropriate value soon. (eg. 9-open) -Rob > On 31 Jan 2018, at 23:47, Martin Buchholz wrote: > > Some automated process marked my backports as "Fixed in 9.0.6" which was > surprising. > Some of us expected the sequence > 9 9.0.1 9.0.2 9.0.3 > but on seeing 9.0.4 we expected the subsequent one to be 9.0.7. > > On Wed, Jan 31, 2018 at 3:30 PM, Martin Buchholz > wrote: > >> My batch of patches has been pushed to jdk-updates/jdk9u/jdk >> From rob.mckenna at oracle.com Mon Feb 5 18:24:28 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 5 Feb 2018 18:24:28 +0000 Subject: [PROPOSED]: New JDK Updates Maintainer process Message-ID: <20180205182428.GA3353@vimes> - After tagging the source code for the last planned update release in the forest they maintain, a maintainer should announce to the jdk-updates-dev mailing list that they plan to step down, provide a timeframe detailing when they intend to step down and call for a new maintainer of the forest. For example, the current set of jdk9u forest maintainers from Oracle now plan to maintain the jdk9u forest until March 2018. The project page will be updated to reflect this shortly. - Suitable maintainers will be added to the OpenJDK JDK Updates Project page [1] by the project lead under the maintainers heading and with a note detailing the forests which they maintain. - Maintainers of a JDK Updates forest may specify alternative codereview & approval mechanisms. -Rob [1] http://openjdk.java.net/projects/jdk-updates/ From gnu.andrew at redhat.com Mon Feb 5 23:17:06 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 5 Feb 2018 23:17:06 +0000 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> Message-ID: On 31 January 2018 at 14:44, dalibor topic wrote: > On 29.01.2018 19:26, Andrew Hughes wrote: >> >> If Oracle want to leave >> future maintainers >> with a "clean slate", there needs to be a concluding feature release >> i.e. something we >> can openly contribute to, as we did under 7 and 8. > > > The role that feature releases used to play in the update release series now > falls squarely onto the shoulders of the major releases. Update releases are > strictly limited to fixes of security issues, regressions, and bugs in newer > features. > I'm aware of this. It remains to be seen how this will work out in practice once we have long term support releases as well. > I don't think that the clean slate is as important in this Project as it was > for 7, when several dozens of patches could accumulate for many months in > the open forest before a final release. > I don't follow you here, because the timing between update releases hasn't changed; they still occur on a quarterly cycle. Major releases are more frequent than before, but they occur under the jdk project, not jdk-updates. I do think that the shorter shelf life of updates like 9 means there will less desire for it to be maintained further, given its consequential lower adoption rate. But that all remains to be seen. What's not clear to me at present how any patches would even make their way into a release. How do changes from the jdk-updates forests make their way into whatever is marked as a release, as this seems to be developed externally and then merged post-release? The problem here occurred because this release was performed behind the scenes and then the code for it dumped in the repository afterwards. There was no opportunity for anyone in the OpenJDK community to test it before release. The argument about patches in the repository already is interesting, but has no relevance to the issue of breakage caused by a change in something which has already been released, but not published. At least this time it was timely, unlike with 9.0.1, which was delayed due to administrative concerns. > In the case of the updates in this Project, I think one can expect at most a > handful or two of additional changes to be requested and approved in the two > months between the last release and the next major release. As I said above, this time period is no different to how it was for OpenJDK 7 & 8. The only exception was when 8u122 was abruptly abandoned with little explanation, and so patches for 8u122, 8u132 and 8u142 all ended up being part of 8u152. Given we seem to have gone back to regular three monthly updates with 8u162, I regard this more as an anomaly than standard practice. > > Given that the requests and approvals and commits [0] can all be easily > tracked, they shouldn't come as a huge surprise to a potential future > maintainer. Well, that link shows us commits. My concern is that the process from request to approval is not transparent. I used the tagging process to get issues included in 8u, as you may remember. Some were approved and some were rejected, but there was no explanation as to why for either. With 8u, I've been able to search for the mails on a backport and discovered why it was approved and why changes were made in the backport. How is the same achieved for 9u and on? > > cheers, > dalibor topic > > [0] > http://mail.openjdk.java.net/pipermail/jdk-updates-changes/2018-January/thread.html > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > 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 > > 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, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From dalibor.topic at oracle.com Tue Feb 6 10:49:36 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 6 Feb 2018 11:49:36 +0100 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> Message-ID: <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> On 06.02.2018 00:17, Andrew Hughes wrote: >> I don't think that the clean slate is as important in this Project as it was >> for 7, when several dozens of patches could accumulate for many months in >> the open forest before a final release. >> > > I don't follow you here, because the timing between update releases hasn't > changed; they still occur on a quarterly cycle. The number of patches that can accumulate in an update release Project's development forest prior to a release can be seen as a function of both time and the bar necessary to meet in order to enter the forest. For most of its development time, that bar for issues entering jdk7u-dev was at effectively at P5 or higher, while the bar for this Project is effectively at P1. So while the timing hasn't changed between 7u and 9u, the bar necessary to pass to enter the forest has. > What's not clear to me at present how any patches would even make their > way into a release. They can do so using the process outlined at http://openjdk.java.net/projects/jdk-updates/approval.html > The problem here occurred because this release was performed behind > the scenes and then the code for it dumped in the repository afterwards. Indeed, every CPU release has been and will be developed in the same way. The scenery and actors may change, thanks to the Vulnerabilty Group, but the happy end won't. ;) > There was no opportunity for anyone in the OpenJDK community to test > it before release. That's not correct. The OpenJDK 9.0.4 release was tested by developers at Oracle. Judging by http://db.openjdk.java.net/people it seems that Oracle employees represent at least a small part of the overall OpenJDK Community. ;) > My concern is that the process from request > to approval is not transparent. Push requests can be tracked here: https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%209-critical-request%20ORDER%20BY%20updated%20DESC When they get approved, they appear here: https://bugs.openjdk.java.net/browse/JDK-8194739?jql=labels%20%3D%209-critical-approved%20ORDER%20BY%20updated%20DESC When they get pushed, they appear here: http://hg.openjdk.java.net/jdk-updates and also at http://mail.openjdk.java.net/pipermail/jdk-updates-changes/ For example, Martin's recent push is listed at http://mail.openjdk.java.net/pipermail/jdk-updates-changes/2018-January/000017.html > With 8u, I've been able to search for the mails on a backport and discovered why > it was approved and why changes were made in the backport. How is the same > achieved for 9u and on? It is much easier to search JBS than mailing lists. For example, https://bugs.openjdk.java.net/browse/JDK-8194739 is Severin's push approval for Zero fixes - it contains a justification, a link to the review thread (on the wrong mailing list, though: posts to jdk9-dev are unlikely to be seen by reviewers once the release reaches GA), and a 9-critical-approval label. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Feb 6 11:50:41 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 6 Feb 2018 12:50:41 +0100 Subject: [PROPOSED]: New JDK Updates Maintainer process In-Reply-To: <20180205182428.GA3353@vimes> References: <20180205182428.GA3353@vimes> Message-ID: <426725a5-7d0e-d15d-054d-9d6a1706d871@oracle.com> On 05.02.2018 19:24, Rob McKenna wrote: > - After tagging the source code for the last planned update release in the > forest they maintain, a maintainer should announce to the > jdk-updates-dev mailing list that they plan to step down, provide a > timeframe detailing when they intend to step down and call for a new > maintainer of the forest. > > For example, the current set of jdk9u forest maintainers from Oracle now > plan to maintain the jdk9u forest until March 2018. The project page > will be updated to reflect this shortly. > > - Suitable maintainers will be added to the OpenJDK JDK Updates Project > page [1] by the project lead under the maintainers heading and with a note > detailing the forests which they maintain. Looks fine to me. In fact, that looks and feels like what we have done for OpenJDK 6, and OpenJDK 7u, just formalized for a setting with multiple active forests. > - Maintainers of a JDK Updates forest may specify alternative codereview & > approval mechanisms. I'm not sure that's strictly necessary for 9u and 10u transitions, but I can see it being useful in LTS releases, for example to distinguish between approvals and reviews destined for multiple branches of the same forest with different maintainers for what's technically the same LTS release series. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From rob.mckenna at oracle.com Tue Feb 6 15:34:36 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 6 Feb 2018 15:34:36 +0000 Subject: [PROPOSED]: New JDK Updates Maintainer process In-Reply-To: <426725a5-7d0e-d15d-054d-9d6a1706d871@oracle.com> References: <20180205182428.GA3353@vimes> <426725a5-7d0e-d15d-054d-9d6a1706d871@oracle.com> Message-ID: <20180206153436.GA3909@vimes> Thanks Dalibor. I'll leave this open for discussion until next Wednesday as its a busy week for some folks. -Rob On 06/02/18 12:50, dalibor topic wrote: > On 05.02.2018 19:24, Rob McKenna wrote: > >- After tagging the source code for the last planned update release in the > > forest they maintain, a maintainer should announce to the > > jdk-updates-dev mailing list that they plan to step down, provide a > > timeframe detailing when they intend to step down and call for a new > > maintainer of the forest. > > > > For example, the current set of jdk9u forest maintainers from Oracle now > > plan to maintain the jdk9u forest until March 2018. The project page > > will be updated to reflect this shortly. > > > >- Suitable maintainers will be added to the OpenJDK JDK Updates Project > > page [1] by the project lead under the maintainers heading and with a note > > detailing the forests which they maintain. > > Looks fine to me. In fact, that looks and feels like what we have done for > OpenJDK 6, and OpenJDK 7u, just formalized for a setting with multiple > active forests. > > >- Maintainers of a JDK Updates forest may specify alternative codereview & > > approval mechanisms. > > I'm not sure that's strictly necessary for 9u and 10u transitions, but I can > see it being useful in LTS releases, for example to distinguish between > approvals and reviews destined for multiple branches of the same forest with > different maintainers for what's technically the same LTS release series. > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > 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 > > 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, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment From gnu.andrew at redhat.com Tue Feb 6 20:51:37 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 6 Feb 2018 20:51:37 +0000 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> Message-ID: <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> On 06.02.2018 21:51, Andrew Hughes wrote: > So we can expect more broken releases in the future? Not from Oracle, as Oracle doesn't plan to release another OpenJDK 9 Update. What platforms the next set of maintainers of the jdk9u forest decide to test their future releases on and how that squares with other people's expectations is a question for them, assuming someone steps up to the task, of course. What took place in the past when Red Hat took over leadership of update releases of 6 and 7 in OpenJDK was an immediate pruning of platforms that releases were tested against: from Windows, Solaris, OS X and Linux to just Linux. If a potential new maintainer for the jdk9u forest decided to adopt a similar approach to re-focusing their platform coverage, I would not be surprised if future jdk9u releases wouldn't build or work on platforms the next set of maintainers didn't chose to build and test on, either. But even if they did test their future release on all possible platforms, a source code release could fail to build downstream using a different, newer (or older) GCC version, a different version of a native library, etc. In short, someone is likely always going to be able to claim that a given release is broken for them in one way or another. They can then use the push approval process to contribute the corresponding changes back. > I find they are roughly similar for searching. Maybe you need a better > mail client if not? Indeed, I don't doubt that local search in your e-mail client works as well as in mine ;) But I am not aware of a mail client that lets me easily share a URL to a search of approved push requests like JBS does: https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%209-critical-approved%20ORDER%20BY%20updated%20DESC . As with so many other things, it's the ability to share results that makes all the difference. ;) > Well, it shows a couple of comments from Severin that would be the equivalent > of an initial e-mail to the list. My concern is the lack of the part > after that; there's > no indication of who approved it or why. You need to go to the history tab to see who modified an issue in what way and when they did so. > Being an approval, that may be a bad example. Is there a case where an issue > was rejected with some explanation? I'm not aware of a rejected push approval for jdk9u so far. I do agree that rejection should come with an explanation, though. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Thu Feb 8 10:26:09 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Feb 2018 10:26:09 +0000 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> Message-ID: <2861b9d6-bde0-3cc4-552b-291edbddc73a@redhat.com> On 07/02/18 16:33, dalibor topic wrote: > In short, someone is likely always going to be able to claim that a > given release is broken for them in one way or another. This shouldn't happen if a proper release process is followed. This wasn't a minor problem: two targets didn't even run. > They can then use the push approval process to contribute the > corresponding changes back. You're missing the point. The last release of jdk9u was not fit for purpose because it broke two targets, and the maintainers of those targets were not given time to fix them. When a release is made it's not just an Oracle release, it's an OpenJDK release, and the release manager should be aware of that. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Thu Feb 8 12:16:16 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 8 Feb 2018 13:16:16 +0100 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: <2861b9d6-bde0-3cc4-552b-291edbddc73a@redhat.com> References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> <2861b9d6-bde0-3cc4-552b-291edbddc73a@redhat.com> Message-ID: On 08.02.2018 11:26, Andrew Haley wrote: >> They can then use the push approval process to contribute the >> corresponding changes back. > > You're missing the point. The last release of jdk9u was not fit for > purpose because it broke two targets, and the maintainers of those > targets were not given time to fix them. The code corresponding to jdk-9.0.4+11 was pushed into jdk9u forest on January 16th, 2018. That's a little bit more than three weeks ago. In those three weeks, one push approval was requested by Severin and approved to fix an issue with the Zero target, specifically https://bugs.openjdk.java.net/browse/JDK-8194739 . It hasn't been pushed yet into the jdk9u forest, but I hope that it will be soon. When it will get pushed into the jdk9u forest is up to Severin, now that the request is approved. Unfortunately, no one has requested to push the changes they might need for the other target you implicitly refer to above (Aarch64, right?) into jdk9u yet. I hope that you or Andrew Dinn will. From what I can tell from http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-January/005274.html and http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-January/005320.html it seems that there were some issues with following processes for pushing the patch into JDK 10 (not very surprising, all things considered, as so many things are brand spanking new now including push approval requests for this Project - it was news to us we'd get any after 9.0.4, after all ;) as well as some other code issues leading to followup changes. So in the case of Aarch64 the actual backport may be a little bit more involved than just labeling a single issue with 9-critical-request. All that being said, please do take your time to do things right for your target platform, and please do not hesitate to ask for help on (or off ;) this list if you need any. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From gnu.andrew at redhat.com Thu Feb 8 22:28:51 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 8 Feb 2018 22:28:51 +0000 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> Message-ID: On 7 February 2018 at 16:33, dalibor topic wrote: > On 06.02.2018 21:51, Andrew Hughes wrote: >> >> So we can expect more broken releases in the future? > > > Not from Oracle, as Oracle doesn't plan to release another OpenJDK 9 Update. > > What platforms the next set of maintainers of the jdk9u forest decide to > test their future releases on and how that squares with other people's > expectations is a question for them, assuming someone steps up to the task, > of course. > > What took place in the past when Red Hat took over leadership of update > releases of 6 and 7 in OpenJDK was an immediate pruning of platforms that > releases were tested against: from Windows, Solaris, OS X and Linux to just > Linux. > > If a potential new maintainer for the jdk9u forest decided to adopt a > similar approach to re-focusing their platform coverage, I would not be > surprised if future jdk9u releases wouldn't build or work on platforms the > next set of maintainers didn't chose to build and test on, either. > > But even if they did test their future release on all possible platforms, a > source code release could fail to build downstream using a different, newer > (or older) GCC version, a different version of a native library, etc. > > In short, someone is likely always going to be able to claim that a given > release is broken for them in one way or another. They can then use the push > approval process to contribute the corresponding changes back. > Actually we do test on Windows; I've just received news of a build failure on the 7u171 we're working on. I believe there are problems with this process in JDK projects maintained both by Oracle and by others. We need to address these issues rather than attempting to assert that the current process works well enough. >> I find they are roughly similar for searching. Maybe you need a better >> mail client if not? > > > Indeed, I don't doubt that local search in your e-mail client works as well > as in mine ;) > > But I am not aware of a mail client that lets me easily share a URL to a > search of approved push requests like JBS does: > https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%209-critical-approved%20ORDER%20BY%20updated%20DESC > . > > As with so many other things, it's the ability to share results that makes > all the difference. ;) > Sharing was irrelevant in the use case I was describing, but this is already vastly off-topic. >> Well, it shows a couple of comments from Severin that would be the >> equivalent >> of an initial e-mail to the list. My concern is the lack of the part >> after that; there's >> no indication of who approved it or why. > > > You need to go to the history tab to see who modified an issue in what way > and when they did so. > It's the why I'd want to know, not the what or when. >> Being an approval, that may be a bad example. Is there a case where an >> issue >> was rejected with some explanation? > > > I'm not aware of a rejected push approval for jdk9u so far. I do agree that > rejection should come with an explanation, though. > There are two issues I see with handling this process on bug reports, one of which is potentially resolvable, and the other which I believe is a disadvantage over the previous system of using e-mails: 1. There is little transparency as to why decisions are made on the bug reports. As we agree, rejections should come with an explanation. I would also hope we would see the same discussion we used to see on the mailing lists when the backport is non-trivial. This is all perfectly possible, but it remains to be seen whether it happens or not. My experience so far is not great. 2. Once you locate discussion on specific bug reports rather than a general mailing list, there is less chance of input from casual observers. I've often checked on the progress of a discussion on the 8u list and ended up reading reviews of other bugs I would not otherwise be aware of. Now I know you'll say people can search for the relevant tag instead, but that still requires some direct action. You're not going to see these things by chance when looking for something else, which I feel is a loss. > > cheers, > dalibor topic > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > 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 > > 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, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 8 22:39:28 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 8 Feb 2018 22:39:28 +0000 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: <2861b9d6-bde0-3cc4-552b-291edbddc73a@redhat.com> References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> <2861b9d6-bde0-3cc4-552b-291edbddc73a@redhat.com> Message-ID: On 8 February 2018 at 10:26, Andrew Haley wrote: > On 07/02/18 16:33, dalibor topic wrote: > >> In short, someone is likely always going to be able to claim that a >> given release is broken for them in one way or another. > > This shouldn't happen if a proper release process is followed. > This wasn't a minor problem: two targets didn't even run. > I'm not a HotSpot developer, and certainly not an AArch64 expert, but it was pretty obvious to me from a casual inspection of the problem changeset that support for these targets was absent. It's also not the first time a target has been broken by a CPU, though it is the first time for AArch64 being part of an upstream release. There was a changeset that fixed this for the PPC targets, which aren't handled by Oracle, as far as I'm aware. So whatever process was used there needs to be expanded to cover other ports. Hopefully the vulnerability group will resolve this. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From martijnverburg at gmail.com Fri Feb 9 04:27:51 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 09 Feb 2018 04:27:51 +0000 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> <2861b9d6-bde0-3cc4-552b-291edbddc73a@redhat.com> Message-ID: Hi all, The Adopt build farm is now also in a place where failures across all platforms will get reported (within 30-60 mins of a push to a repo). We?re still shy of regularly passing JCKs, but once we cross that milestone then I?ll start a serious discussion on how we can best feed failures etc back into OpenJDK mailing lists. Cheers, Martijn On Fri, 9 Feb 2018 at 06:40, Andrew Hughes wrote: > On 8 February 2018 at 10:26, Andrew Haley wrote: > > On 07/02/18 16:33, dalibor topic wrote: > > > >> In short, someone is likely always going to be able to claim that a > >> given release is broken for them in one way or another. > > > > This shouldn't happen if a proper release process is followed. > > This wasn't a minor problem: two targets didn't even run. > > > > I'm not a HotSpot developer, and certainly not an AArch64 expert, > but it was pretty obvious to me from a casual inspection of the > problem changeset that support for these targets was absent. > It's also not the first time a target has been broken by a CPU, > though it is the first time for AArch64 being part of an upstream > release. > > There was a changeset that fixed this for the PPC targets, which > aren't handled by Oracle, as far as I'm aware. So whatever > process was used there needs to be expanded to cover other > ports. Hopefully the vulnerability group will resolve this. > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > -- Cheers, Martijn (Sent from Gmail Mobile) From volker.simonis at gmail.com Fri Feb 9 09:40:17 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 9 Feb 2018 10:40:17 +0100 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> <2861b9d6-bde0-3cc4-552b-291edbddc73a@redhat.com> Message-ID: On Thu, Feb 8, 2018 at 11:39 PM, Andrew Hughes wrote: > On 8 February 2018 at 10:26, Andrew Haley wrote: >> On 07/02/18 16:33, dalibor topic wrote: >> >>> In short, someone is likely always going to be able to claim that a >>> given release is broken for them in one way or another. >> >> This shouldn't happen if a proper release process is followed. >> This wasn't a minor problem: two targets didn't even run. >> > > I'm not a HotSpot developer, and certainly not an AArch64 expert, > but it was pretty obvious to me from a casual inspection of the > problem changeset that support for these targets was absent. > It's also not the first time a target has been broken by a CPU, > though it is the first time for AArch64 being part of an upstream > release. > > There was a changeset that fixed this for the PPC targets, which > aren't handled by Oracle, as far as I'm aware. So whatever > process was used there needs to be expanded to cover other > ports. Hopefully the vulnerability group will resolve this. The process used there was our commercial licensee channel which isn't usable for OpenJDK. So all the hope is on the vulnerability group! > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Mon Feb 12 11:06:32 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 12 Feb 2018 11:06:32 +0000 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 Message-ID: Following Dalibor's suggestion in the thread entitled Future jdk9u updates & 9-critical-request I have tagged the following critical defects with tag 9-critical-request and am asking for them fixes to be backported to jdk9u. Note that JDK-8195685 requires JDK-8196136 as a follow-up fix to correct an error in register use JDK-8195858 requires JDK-8196221 as a follow-up fix to correct a missing argument error in the first of these two patches All the original jdk10/11 patches apply without code changes, per se. Obviously, the file paths mentioned in the original need tweaking to allow for the re-organization of the code tree. Apologies for the delay in posting this -- the FOSDEM lurgie strikes yet again. regards, Andrew Dinn ----------- From dalibor.topic at oracle.com Mon Feb 12 13:57:44 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 12 Feb 2018 14:57:44 +0100 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 In-Reply-To: References: Message-ID: <7a39e1a6-cc99-e68c-b45b-7e63f23298f7@oracle.com> On 12.02.2018 12:06, Andrew Dinn wrote: > Following Dalibor's suggestion in the thread entitled > > Future jdk9u updates & 9-critical-request > > I have tagged the following critical defects with tag 9-critical-request > and am asking for them fixes to be backported to jdk9u. Thanks, Andrew! > Apologies for the delay in posting this -- the FOSDEM lurgie strikes yet > again. No worries, and I hope [0] you're feeling better! cheers, dalibor topic [0] https://www.urbandictionary.com/define.php?term=Lurgy sadly seems to have lost its fictional meaning over the years. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From martinrb at google.com Mon Feb 12 18:15:45 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 12 Feb 2018 10:15:45 -0800 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 In-Reply-To: References: Message-ID: On Mon, Feb 12, 2018 at 3:06 AM, Andrew Dinn wrote: > > All the original jdk10/11 patches apply without code changes, per se. > Obviously, the file paths mentioned in the original need tweaking to > allow for the re-organization of the code tree. > FYI - For my jdk9u backports I successfully used bin/unshuffle_patch.sh to obtain "fully automated" backports. From dalibor.topic at oracle.com Tue Feb 13 08:23:39 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 13 Feb 2018 09:23:39 +0100 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 In-Reply-To: <7a39e1a6-cc99-e68c-b45b-7e63f23298f7@oracle.com> References: <7a39e1a6-cc99-e68c-b45b-7e63f23298f7@oracle.com> Message-ID: <19edad58-2324-80b2-b7b9-eda78bf3a51c@oracle.com> On 12.02.2018 14:57, dalibor topic wrote: > On 12.02.2018 12:06, Andrew Dinn wrote: >> Following Dalibor's suggestion in the thread entitled >> >> ?? Future jdk9u updates & 9-critical-request >> >> I have tagged the following critical defects with tag 9-critical-request >> and am asking for them fixes to be backported to jdk9u. > > Thanks, Andrew! Looks like they've all been approved. Rob, what do you think about tagging jdk-9.0.4+12 once Andrew and Severin push the fixes for Aarch64 & Zero? cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From adinn at redhat.com Tue Feb 13 10:17:57 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 13 Feb 2018 10:17:57 +0000 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 In-Reply-To: <19edad58-2324-80b2-b7b9-eda78bf3a51c@oracle.com> References: <7a39e1a6-cc99-e68c-b45b-7e63f23298f7@oracle.com> <19edad58-2324-80b2-b7b9-eda78bf3a51c@oracle.com> Message-ID: Hi Dalibor, On 13/02/18 08:23, dalibor topic wrote: > Looks like they've all been approved. And ... I have just backported and pushed all the change sets. n.b I pushed the changes I requested plus the one requested by Severin -- he is away on parental leave so I am sure he has more important things on his mind. > Rob, what do you think about tagging jdk-9.0.4+12 once Andrew and > Severin push the fixes for Aarch64 & Zero? That would be very welcome. Thanks to both of you for your help and co-operation. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Feb 13 10:26:53 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 13 Feb 2018 10:26:53 +0000 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 In-Reply-To: References:

Message-ID: <0a49a9cb-ff83-d7ca-7131-7981ebd8e55b@redhat.com> Hi Martin, On 12/02/18 18:15, Martin Buchholz wrote: > FYI - For my jdk9u backports I successfully used??bin/unshuffle_patch.sh > to obtain "fully automated" backports. Thanks for the tip. I tried this and it didn't quite work (n.b. I passed options -r hotspot and -to9). All the paths in the patch still contained src/hotspot/... where it should just have been src/... Also, the script did not interpose the necessary vm subdir (as in src/cpu/aarch64/vm/... or src/share/vm/interpreter/...) I'm not sure if your success was because you backported e.g. jdk changes rather than hotspot changes or if I passed the wrong arguments. Anyway, a quick emacs session sorted things out :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dalibor.topic at oracle.com Fri Feb 16 08:30:33 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 16 Feb 2018 09:30:33 +0100 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 In-Reply-To: References: <7a39e1a6-cc99-e68c-b45b-7e63f23298f7@oracle.com> <19edad58-2324-80b2-b7b9-eda78bf3a51c@oracle.com> Message-ID: <90cf570f-cc49-5c44-96d0-04c0e4a18d9d@oracle.com> On 13.02.2018 11:17, Andrew Dinn wrote: > Hi Dalibor, > > On 13/02/18 08:23, dalibor topic wrote: >> Looks like they've all been approved. > > And ... I have just backported and pushed all the change sets. n.b I > pushed the changes I requested plus the one requested by Severin -- he > is away on parental leave so I am sure he has more important things on > his mind. Thanks, Andrew - and all the best to Severin! >> Rob, what do you think about tagging jdk-9.0.4+12 once Andrew and >> Severin push the fixes for Aarch64 & Zero? > That would be very welcome. Thanks to both of you for your help and > co-operation. Just to wrap up this thread, Rob tagged 9.0.4+12 on Wednesday [0]. Thanks, Rob! cheers, dalibor topic [0] http://mail.openjdk.java.net/pipermail/jdk-updates-changes/2018-February/thread.html -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Feb 16 13:55:20 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 16 Feb 2018 14:55:20 +0100 Subject: Future jdk9u updates & 9-critical-request In-Reply-To: References: <20180112151935.GC4779@vimes>

<20180117150118.GA3420@vimes> <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com> <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com> <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com> <0ca61ece-7178-2865-2f52-0f5a0c398348@oracle.com> <0f439358-463d-bc90-fe3e-0e74e19e9947@oracle.com> Message-ID: <36f43e9f-731e-c71c-6361-513c3af3b987@oracle.com> On 08.02.2018 23:28, Andrew Hughes wrote: > I > would also hope we would see the same discussion we used to see on > the mailing lists when the backport is non-trivial. This is all perfectly > possible, but it remains to be seen whether it happens or not. I don't see a problem with using JBS to record push requests and their (dis)approvals, while continuing to use the mailing list for non-trivial discussions, like this one. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From rob.mckenna at oracle.com Fri Feb 16 14:20:18 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 16 Feb 2018 14:20:18 +0000 Subject: Request for backport to jdk9u: JDK-8195685, JDK-8196136, JDK-8195858, JDK-8196221 In-Reply-To: <90cf570f-cc49-5c44-96d0-04c0e4a18d9d@oracle.com> References: <7a39e1a6-cc99-e68c-b45b-7e63f23298f7@oracle.com> <19edad58-2324-80b2-b7b9-eda78bf3a51c@oracle.com> <90cf570f-cc49-5c44-96d0-04c0e4a18d9d@oracle.com> Message-ID: <20180216142018.GA6850@vimes> NP, meant to send a mail out and was distracted. -Rob On 16/02/18 09:30, dalibor topic wrote: > > > On 13.02.2018 11:17, Andrew Dinn wrote: > >Hi Dalibor, > > > >On 13/02/18 08:23, dalibor topic wrote: > >>Looks like they've all been approved. > > > >And ... I have just backported and pushed all the change sets. n.b I > >pushed the changes I requested plus the one requested by Severin -- he > >is away on parental leave so I am sure he has more important things on > >his mind. > > Thanks, Andrew - and all the best to Severin! > > >>Rob, what do you think about tagging jdk-9.0.4+12 once Andrew and > >>Severin push the fixes for Aarch64 & Zero? > >That would be very welcome. Thanks to both of you for your help and > >co-operation. > Just to wrap up this thread, Rob tagged 9.0.4+12 on Wednesday [0]. Thanks, > Rob! > > cheers, > dalibor topic > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-changes/2018-February/thread.html > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > 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 > > 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, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment From rob.mckenna at oracle.com Fri Feb 16 14:22:18 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 16 Feb 2018 14:22:18 +0000 Subject: [PROPOSED]: New JDK Updates Maintainer process In-Reply-To: <20180206153436.GA3909@vimes> References: <20180205182428.GA3353@vimes> <426725a5-7d0e-d15d-054d-9d6a1706d871@oracle.com> <20180206153436.GA3909@vimes> Message-ID: <20180216142218.GB6850@vimes> Hearing no objections we will adopt this process from here on out. -Rob On 06/02/18 15:34, Rob McKenna wrote: > Thanks Dalibor. I'll leave this open for discussion until next > Wednesday as its a busy week for some folks. > > -Rob > > On 06/02/18 12:50, dalibor topic wrote: > > On 05.02.2018 19:24, Rob McKenna wrote: > > >- After tagging the source code for the last planned update release in the > > > forest they maintain, a maintainer should announce to the > > > jdk-updates-dev mailing list that they plan to step down, provide a > > > timeframe detailing when they intend to step down and call for a new > > > maintainer of the forest. > > > > > > For example, the current set of jdk9u forest maintainers from Oracle now > > > plan to maintain the jdk9u forest until March 2018. The project page > > > will be updated to reflect this shortly. > > > > > >- Suitable maintainers will be added to the OpenJDK JDK Updates Project > > > page [1] by the project lead under the maintainers heading and with a note > > > detailing the forests which they maintain. > > > > Looks fine to me. In fact, that looks and feels like what we have done for > > OpenJDK 6, and OpenJDK 7u, just formalized for a setting with multiple > > active forests. > > > > >- Maintainers of a JDK Updates forest may specify alternative codereview & > > > approval mechanisms. > > > > I'm not sure that's strictly necessary for 9u and 10u transitions, but I can > > see it being useful in LTS releases, for example to distinguish between > > approvals and reviews destined for multiple branches of the same forest with > > different maintainers for what's technically the same LTS release series. > > > > cheers, > > dalibor topic > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > 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 > > > > 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, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment From rob.mckenna at oracle.com Fri Feb 16 15:44:50 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 16 Feb 2018 15:44:50 +0000 Subject: [9u Communication] End of maintenance timeframe & invitation for prospective new maintainers Message-ID: <20180216154450.GC6850@vimes> In line with the new process [1] I'm sending a mail out to notify the community that the current maintainers intend to step down as maintainers for the JDK 9 Updates forest [2] at the end of March. This being the case we would like to invite prospective new maintainers to step forward at this point to ensure a smooth transition should they wish to maintain this forest beyond the end of March. Meawhile, we're in the process of preparing a jdk10u forest for this Project, which I and the other maintainers from Oracle plan to maintain going forward until we step down. I'll send an update to the alias once it's available. Also, Dalibor will purchase a beer at next years Fosdem for anyone who can come up with an equally informative but less clunky subject line for this mail. -Rob [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-February/000064.html [2] http://hg.openjdk.java.net/jdk-updates/jdk9u