From rob.mckenna at oracle.com Wed Nov 1 14:20:17 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 1 Nov 2017 14:20:17 +0000 Subject: Request for Approval: Backport of JDK-8188030: AWT java apps fail to start when some minimal fonts are present In-Reply-To: References: Message-ID: <20171101142017.GB3122@vimes> Hi Mario, Thanks for the request. (the first for the JDK Updates project!) We're just finalizing a draft of the processes around the JDK Updates project and will hopefully publish that later today. I'd like to solicit feedback on that before tackling individual backport requests but I'll get back to you as soon as that discussion is complete. Thanks, -Rob On 30/10/17 14:10, Mario Torre wrote: > Hi all, > > I would like to backport the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8188030 > > to http://hg.openjdk.java.net/jdk-updates/jdk9u/ > > The fix is the same as OpenJDK10 [1] and applies cleanly: > > http://cr.openjdk.java.net/~neugens/8188030/webrev.01 > > I'm not sure if I need to manually create a backport request on the > bug database, I remember that that was done automatically but it > doesn't seem like it has been created yet. > > Cheers, > Mario > > [1] http://hg.openjdk.java.net/jdk10/client/rev/d5a1cde89944 From neugens at redhat.com Fri Nov 3 14:49:53 2017 From: neugens at redhat.com (Mario Torre) Date: Fri, 3 Nov 2017 15:49:53 +0100 Subject: Request for Approval: Backport of JDK-8188030: AWT java apps fail to start when some minimal fonts are present In-Reply-To: <20171101142017.GB3122@vimes> References: <20171101142017.GB3122@vimes> Message-ID: On Wed, Nov 1, 2017 at 3:20 PM, Rob McKenna wrote: > Hi Mario, > > Thanks for the request. (the first for the JDK Updates project!) We're > just finalizing a draft of the processes around the JDK Updates project > and will hopefully publish that later today. I'd like to solicit > feedback on that before tackling individual backport requests > but I'll get back to you as soon as that discussion is complete. > Hi Rob, Thanks, I'm glad to test case the new process :) I didn't see the draft,was it already published? Cheers, Mario From rob.mckenna at oracle.com Mon Nov 6 14:51:42 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 6 Nov 2017 14:51:42 +0000 Subject: JDK Updates Project Page Message-ID: <20171106145142.GA3032@vimes> The JDK Updates Project page has been updated with new, draft rules with the intention of streamlining project management: http://openjdk.java.net/projects/jdk-updates/ I'd like to leave the draft rules open for discussion for a week, so please let me know if you have any comments. -Rob From rob.mckenna at oracle.com Mon Nov 6 14:52:15 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 6 Nov 2017 14:52:15 +0000 Subject: Request for Approval: Backport of JDK-8188030: AWT java apps fail to start when some minimal fonts are present In-Reply-To: References: <20171101142017.GB3122@vimes> Message-ID: <20171106145215.GB3032@vimes> Just! Apologies for the delay. -Rob On 03/11/17 15:49, Mario Torre wrote: > On Wed, Nov 1, 2017 at 3:20 PM, Rob McKenna wrote: > > Hi Mario, > > > > Thanks for the request. (the first for the JDK Updates project!) We're > > just finalizing a draft of the processes around the JDK Updates project > > and will hopefully publish that later today. I'd like to solicit > > feedback on that before tackling individual backport requests > > but I'll get back to you as soon as that discussion is complete. > > > > Hi Rob, > > Thanks, I'm glad to test case the new process :) > > I didn't see the draft,was it already published? > > Cheers, > Mario From scolebourne at joda.org Mon Nov 6 14:57:20 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 6 Nov 2017 14:57:20 +0000 Subject: JDK Updates Project Page In-Reply-To: <20171106145142.GA3032@vimes> References: <20171106145142.GA3032@vimes> Message-ID: Isn't it v9.0.2 in January? Stephen On 6 November 2017 at 14:51, Rob McKenna wrote: > The JDK Updates Project page has been updated with new, draft rules with > the intention of streamlining project management: > > http://openjdk.java.net/projects/jdk-updates/ > > I'd like to leave the draft rules open for discussion for a week, so > please let me know if you have any comments. > > -Rob > From neugens at redhat.com Mon Nov 6 15:01:05 2017 From: neugens at redhat.com (Mario Torre) Date: Mon, 6 Nov 2017 16:01:05 +0100 Subject: Request for Approval: Backport of JDK-8188030: AWT java apps fail to start when some minimal fonts are present In-Reply-To: <20171106145215.GB3032@vimes> References: <20171101142017.GB3122@vimes> <20171106145215.GB3032@vimes> Message-ID: On Mon, Nov 6, 2017 at 3:52 PM, Rob McKenna wrote: > Just! Apologies for the delay. No worries! Cheers, Mario From rob.mckenna at oracle.com Mon Nov 6 16:35:20 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 6 Nov 2017 16:35:20 +0000 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> Message-ID: <20171106163520.GD3032@vimes> We're not planning to change the numbering scheme for JDK9 currently. (though we reserve the right to do it in the future! I'll keep you posted) -Rob On 06/11/17 14:57, Stephen Colebourne wrote: > Isn't it v9.0.2 in January? > Stephen > > On 6 November 2017 at 14:51, Rob McKenna wrote: > > The JDK Updates Project page has been updated with new, draft rules with > > the intention of streamlining project management: > > > > http://openjdk.java.net/projects/jdk-updates/ > > > > I'd like to leave the draft rules open for discussion for a week, so > > please let me know if you have any comments. > > > > -Rob > > From neugens at redhat.com Thu Nov 9 11:50:11 2017 From: neugens at redhat.com (Mario Torre) Date: Thu, 9 Nov 2017 12:50:11 +0100 Subject: JDK Updates Project Page In-Reply-To: <20171106145142.GA3032@vimes> References: <20171106145142.GA3032@vimes> Message-ID: Hi Rob, I went through the documents, and I have a couple of comments/questions. The document is simple enough to understand even for me, so that's a good signal, I would personally put everything in a single page though. Since this is a process, a diagram of the actions rather than a list of rules may be even easier to understand, with the benefit of indicating exactly who is responsible for what at any given step (the need, for example, to involve the original reviewers/contributors of the patch, is that a requirement for each backport or just a suggestion? I believe than as much as possible, the original authors should be involved again in the process, the only case where this doesn't apply is either of them is not available, in this case is the Lead call to request info). You mention that you need to label the corresponding master/parent issue with the -critical-request tag, it's not clear to me if this is something we need to do after the bug has been reviewed for backport, in which case it seems redundant, or if it's a pre-requisite for the review step to even begin (which means that the "Public Code Review" process is parallel to the "Requesting push approval for fixes"). It's not clear to me why a backport request needs to be critical to be approved. A backport may not be critical, but still more than just a nice to have feature that warrant the code change. For example, the bug I submitted (which from now on will be our test case!), is not exactly critical, but it's clearly something that touches many users especially in a server like environment with a limited install base, which qualifies it to be more than just "nice to have". In fact, the list of critical bugs mention P1, while this bug is P4. It's not a regression either, strictly speaking, since it's about installed fonts on the system. The criticality of the bug may be perceived differently then, depending on who is reviewing the fix. I would personally reserve the "critical" term for actual really critical issues (a security emergency fix for example, or, indeed, a P1 bug), but have another flag to signal the backport request, unless the point of this exercise is really to not have upstream backport requests any more other than, well, critical ones [1]. There's another concern about this point. A bug is generally discovered on a lower jdk version, usually the one in production. For instance, this issue was discovered in 8. If only critical issues are to be backported, it means that an issue in 8 needs to go in 10 currently, but can't be ported to 8 and 7 if the updates in between don't mark the issue as critical at any given point. Maybe I'm just giving too much importance on the term "critical" here, though. Cheers, Mario [1] In which case, rule #1 should really be "do not talk about backports" ;) On Mon, Nov 6, 2017 at 3:51 PM, Rob McKenna wrote: > The JDK Updates Project page has been updated with new, draft rules with > the intention of streamlining project management: > > http://openjdk.java.net/projects/jdk-updates/ > > I'd like to leave the draft rules open for discussion for a week, so > please let me know if you have any comments. > > -Rob > From david.holmes at oracle.com Thu Nov 9 12:26:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Nov 2017 22:26:28 +1000 Subject: JDK Updates Project Page In-Reply-To: <20171106145142.GA3032@vimes> References: <20171106145142.GA3032@vimes> Message-ID: Hi Rob, On 7/11/2017 12:51 AM, Rob McKenna wrote: > The JDK Updates Project page has been updated with new, draft rules with > the intention of streamlining project management: > > http://openjdk.java.net/projects/jdk-updates/ There's no "Push Approval Request Template" - is that no longer needed? Thanks, David > I'd like to leave the draft rules open for discussion for a week, so > please let me know if you have any comments. > > -Rob > From neugens at redhat.com Thu Nov 9 12:30:20 2017 From: neugens at redhat.com (Mario Torre) Date: Thu, 9 Nov 2017 13:30:20 +0100 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> Message-ID: On Thu, Nov 9, 2017 at 1:26 PM, David Holmes wrote: > Hi Rob, > > On 7/11/2017 12:51 AM, Rob McKenna wrote: >> >> The JDK Updates Project page has been updated with new, draft rules with >> the intention of streamlining project management: >> >> http://openjdk.java.net/projects/jdk-updates/ > > > There's no "Push Approval Request Template" - is that no longer needed? Isn't that one? http://openjdk.java.net/projects/jdk-updates/approval.html Cheers, Mario From david.holmes at oracle.com Thu Nov 9 12:35:52 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Nov 2017 22:35:52 +1000 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> Message-ID: <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> On 9/11/2017 10:30 PM, Mario Torre wrote: > On Thu, Nov 9, 2017 at 1:26 PM, David Holmes wrote: >> Hi Rob, >> >> On 7/11/2017 12:51 AM, Rob McKenna wrote: >>> >>> The JDK Updates Project page has been updated with new, draft rules with >>> the intention of streamlining project management: >>> >>> http://openjdk.java.net/projects/jdk-updates/ >> >> >> There's no "Push Approval Request Template" - is that no longer needed? > > Isn't that one? > > http://openjdk.java.net/projects/jdk-updates/approval.html For 8u we have a request template: http://openjdk.java.net/projects/jdk8u/approval-template.html Cheers, David > Cheers, > Mario > From david.holmes at oracle.com Thu Nov 9 12:37:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Nov 2017 22:37:39 +1000 Subject: JDK Updates Project Page In-Reply-To: <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> Message-ID: <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> Oh I see now ... On 9/11/2017 10:35 PM, David Holmes wrote: > On 9/11/2017 10:30 PM, Mario Torre wrote: >> On Thu, Nov 9, 2017 at 1:26 PM, David Holmes >> wrote: >>> Hi Rob, >>> >>> On 7/11/2017 12:51 AM, Rob McKenna wrote: >>>> >>>> The JDK Updates Project page has been updated with new, draft rules >>>> with >>>> the intention of streamlining project management: >>>> >>>> http://openjdk.java.net/projects/jdk-updates/ >>> >>> >>> There's no "Push Approval Request Template" - is that no longer needed? >> >> Isn't that one? >> >> http://openjdk.java.net/projects/jdk-updates/approval.html > > For 8u we have a request template: > > http://openjdk.java.net/projects/jdk8u/approval-template.html For jdk-updates we're using a JBS based process with no email request. David > Cheers, > David > >> Cheers, >> Mario >> From neugens at redhat.com Thu Nov 9 12:43:34 2017 From: neugens at redhat.com (Mario Torre) Date: Thu, 9 Nov 2017 13:43:34 +0100 Subject: JDK Updates Project Page In-Reply-To: <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> Message-ID: On Thu, Nov 9, 2017 at 1:37 PM, David Holmes wrote: > Oh I see now ... > > On 9/11/2017 10:35 PM, David Holmes wrote: >> >> On 9/11/2017 10:30 PM, Mario Torre wrote: >>> >>> On Thu, Nov 9, 2017 at 1:26 PM, David Holmes >>> wrote: >>>> >>>> Hi Rob, >>>> >>>> On 7/11/2017 12:51 AM, Rob McKenna wrote: >>>>> >>>>> >>>>> The JDK Updates Project page has been updated with new, draft rules >>>>> with >>>>> the intention of streamlining project management: >>>>> >>>>> http://openjdk.java.net/projects/jdk-updates/ >>>> >>>> >>>> >>>> There's no "Push Approval Request Template" - is that no longer needed? >>> >>> >>> Isn't that one? >>> >>> http://openjdk.java.net/projects/jdk-updates/approval.html >> >> >> For 8u we have a request template: >> >> http://openjdk.java.net/projects/jdk8u/approval-template.html > > > For jdk-updates we're using a JBS based process with no email request. Right, I see what you mean. It makes sense to have exclusively at JBS based process. We will still need to ask for review via email, but I think having a template for that may be overkill. Do we expect emails on jdk-updates-dev to be anything but backport requests? Cheers, Mario From neugens at redhat.com Thu Nov 9 13:16:12 2017 From: neugens at redhat.com (Mario Torre) Date: Thu, 9 Nov 2017 14:16:12 +0100 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> Message-ID: On Thu, Nov 9, 2017 at 1:43 PM, Mario Torre wrote: > Right, I see what you mean. It makes sense to have exclusively at JBS > based process. We will still need to ask for review via email, but I > think having a template for that may be overkill. Do we expect emails > on jdk-updates-dev to be anything but backport requests? It now occurred to me that the process may be just done exclusively on JBS, including the review process: 1. A developer wants to backport a fix from n+1 into n creates a backport request (marking the bug backport-request or whatever) 2. The bug is updated with links to the new webrev and all the information needed 3. The review happens on the bug tracking system. The Lead either approves the backport request or ask the original reviewer for review. 4. If the request is approve, the bug can be backported 5. Repeat for each backport version (perhaps is worth to create separate bugs for each backport) Assuming that for 8 and 7 there is still the old process in place and that there is just one update-dev at any given time (two with the LTS), the process seems quite streamlined. It's not different than what is being proposed, just happens on the bug tracking system and not on the mailing list, which is nice since it's easier to see the reasoning behind each bug and recreate its history. What do you think, would that be of any help? Cheers, Mario From philip.race at oracle.com Thu Nov 9 20:53:55 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 9 Nov 2017 12:53:55 -0800 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> Message-ID: On 11/09/2017 03:50 AM, Mario Torre wrote: > Hi Rob, > > I went through the documents, and I have a couple of comments/questions. > > The document is simple enough to understand even for me, so that's a > good signal, I would personally put everything in a single page > though. +1 to that. The back and forth navigation is too much overhead for the small amount of content on each page. > Since this is a process, a diagram of the actions rather than > a list of rules may be even easier to understand, with the benefit of > indicating exactly who is responsible for what at any given step (the > need, for example, to involve the original reviewers/contributors of > the patch, is that a requirement for each backport or just a > suggestion? I believe than as much as possible, the original authors > should be involved again in the process, the only case where this > doesn't apply is either of them is not available, in this case is the > Lead call to request info). > > You mention that you need to label the corresponding master/parent > issue with the -critical-request tag, it's not clear to me if > this is something we need to do after the bug has been reviewed for > backport, in which case it seems redundant, or if it's a pre-requisite > for the review step to even begin (which means that the "Public Code > Review" process is parallel to the "Requesting push approval for > fixes"). > > It's not clear to me why a backport request needs to be critical to be > approved. A backport may not be critical, but still more than just a > nice to have feature that warrant the code change. For example, the > bug I submitted (which from now on will be our test case!), is not > exactly critical, but it's clearly something that touches many users > especially in a server like environment with a limited install base, > which qualifies it to be more than just "nice to have". In fact, the > list of critical bugs mention P1, while this bug is P4. It's not a > regression either, strictly speaking, since it's about installed fonts > on the system. Mario, I think the issue here is that the only planned update releases for JDK 9 and JDK 10 are CPU releases. That's the model going forward. And CPU releases only get absolutely critical fixes .. of which the security fixes are the main category. So there won't be a long tail of 9.0.XXX releases like we had JDK 8 updates / PSUs which need these backports. Backports will become increasingly rare. Consider that 8u152 had maybe a year of backlogged fixes. Some fixes we pushed in May (?) to 8u-dev are only just showing up in 8u162 b01 for release next year .. But JDK 10 will be out just 6 months after JDK 9 .. and 9 will then become obsolete and unsupported .. so why does it need non-critical backports anyway ? People should be on 10 by then. Backports are going to become rare if I have my facts right. > > The criticality of the bug may be perceived differently then, > depending on who is reviewing the fix. I would personally reserve the > "critical" term for actual really critical issues (a security > emergency fix for example, or, indeed, a P1 bug), but have another > flag to signal the backport request, unless the point of this exercise > is really to not have upstream backport requests any more other than, > well, critical ones [1]. > > There's another concern about this point. A bug is generally > discovered on a lower jdk version, usually the one in production. For > instance, this issue was discovered in 8. If only critical issues are > to be backported, it means that an issue in 8 needs to go in 10 > currently, but can't be ported to 8 and 7 if the updates in between > don't mark the issue as critical at any given point. It is something I am still getting my head around that we may have a fix in 8 and 10 but not 9 .. when we've always previously had the rule that a fix in release N must also be in N+M for all values of M. And an LTS like JDK 11 might acquire a fix that isn't in 12, 13, 14, 15 .. if it is found and fixed in the 16 time frame. -phil. > > Maybe I'm just giving too much importance on the term "critical" here, though. > > Cheers, > Mario > > [1] In which case, rule #1 should really be "do not talk about backports" ;) > > > On Mon, Nov 6, 2017 at 3:51 PM, Rob McKenna wrote: >> The JDK Updates Project page has been updated with new, draft rules with >> the intention of streamlining project management: >> >> http://openjdk.java.net/projects/jdk-updates/ >> >> I'd like to leave the draft rules open for discussion for a week, so >> please let me know if you have any comments. >> >> -Rob >> From rob.mckenna at oracle.com Fri Nov 10 15:40:17 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 10 Nov 2017 15:40:17 +0000 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> Message-ID: <20171110154017.GB4196@vimes> Thanks for the feedback, 1) Moving to a single page makes sense, we can always split it up as necessary if we end up adding to the process docs. 2) As David notes the bug approval process will be JBS only, no email template involved. 3) We're sticking with the current codereview practices for a couple of reasons: - Codereview is a contentious issue and out of scope for the updates project - Moving to JBS would limit participation to those with JBS logins - Reviewers are used to monitoring the appropriate email aliases, introducing a separate process for them to follow would introduce unnecessary complications 4) As noted in the approval page, the public codereview must be completed prior to requesting critical approval. 5) We're setting a higher bar here for update release content. The process page specifies P1 bugs & serious regressions. If a fix is not critical then it can likely wait until the next feature release which will be available within 6 months. (this has the added benefit of incentivizing users to pick up JDK fixes faster) 6) As Phil noted, we're moving to a model where we no longer mandate that backports need to be fixed in all releases between the next feature and the backport release. -Rob On 09/11/17 14:16, Mario Torre wrote: > On Thu, Nov 9, 2017 at 1:43 PM, Mario Torre wrote: > > > Right, I see what you mean. It makes sense to have exclusively at JBS > > based process. We will still need to ask for review via email, but I > > think having a template for that may be overkill. Do we expect emails > > on jdk-updates-dev to be anything but backport requests? > > It now occurred to me that the process may be just done exclusively on > JBS, including the review process: > > 1. A developer wants to backport a fix from n+1 into n creates a > backport request (marking the bug backport-request or whatever) > 2. The bug is updated with links to the new webrev and all the > information needed > 3. The review happens on the bug tracking system. The Lead either > approves the backport request or ask the original reviewer for review. > 4. If the request is approve, the bug can be backported > 5. Repeat for each backport version (perhaps is worth to create > separate bugs for each backport) > > Assuming that for 8 and 7 there is still the old process in place and > that there is just one update-dev at any given time (two with the > LTS), the process seems quite streamlined. It's not different than > what is being proposed, just happens on the bug tracking system and > not on the mailing list, which is nice since it's easier to see the > reasoning behind each bug and recreate its history. > > What do you think, would that be of any help? > > Cheers, > Mario From rob.mckenna at oracle.com Fri Nov 10 15:58:06 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 10 Nov 2017 15:58:06 +0000 Subject: JDK Updates Project Page In-Reply-To: <20171110154017.GB4196@vimes> References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> <20171110154017.GB4196@vimes> Message-ID: <20171110155806.GC4196@vimes> Correcting a typo in Phil's address. -Rob On 10/11/17 15:40, Rob McKenna wrote: > Thanks for the feedback, > > 1) Moving to a single page makes sense, we can always split it up as > necessary if we end up adding to the process docs. > > 2) As David notes the bug approval process will be JBS only, no email > template involved. > > 3) We're sticking with the current codereview practices for a couple of > reasons: > > - Codereview is a contentious issue and out of scope for the updates > project > - Moving to JBS would limit participation to those with JBS logins > - Reviewers are used to monitoring the appropriate email aliases, > introducing a separate process for them to follow would introduce > unnecessary complications > > 4) As noted in the approval page, the public codereview must be > completed prior to requesting critical approval. > > 5) We're setting a higher bar here for update release content. The > process page specifies P1 bugs & serious regressions. If a fix is not > critical then it can likely wait until the next feature release which will > be available within 6 months. (this has the added benefit of incentivizing > users to pick up JDK fixes faster) > > 6) As Phil noted, we're moving to a model where we no longer mandate > that backports need to be fixed in all releases between the next feature > and the backport release. > > -Rob > > On 09/11/17 14:16, Mario Torre wrote: > > On Thu, Nov 9, 2017 at 1:43 PM, Mario Torre wrote: > > > > > Right, I see what you mean. It makes sense to have exclusively at JBS > > > based process. We will still need to ask for review via email, but I > > > think having a template for that may be overkill. Do we expect emails > > > on jdk-updates-dev to be anything but backport requests? > > > > It now occurred to me that the process may be just done exclusively on > > JBS, including the review process: > > > > 1. A developer wants to backport a fix from n+1 into n creates a > > backport request (marking the bug backport-request or whatever) > > 2. The bug is updated with links to the new webrev and all the > > information needed > > 3. The review happens on the bug tracking system. The Lead either > > approves the backport request or ask the original reviewer for review. > > 4. If the request is approve, the bug can be backported > > 5. Repeat for each backport version (perhaps is worth to create > > separate bugs for each backport) > > > > Assuming that for 8 and 7 there is still the old process in place and > > that there is just one update-dev at any given time (two with the > > LTS), the process seems quite streamlined. It's not different than > > what is being proposed, just happens on the bug tracking system and > > not on the mailing list, which is nice since it's easier to see the > > reasoning behind each bug and recreate its history. > > > > What do you think, would that be of any help? > > > > Cheers, > > Mario From neugens at redhat.com Fri Nov 10 16:24:15 2017 From: neugens at redhat.com (Mario Torre) Date: Fri, 10 Nov 2017 17:24:15 +0100 Subject: JDK Updates Project Page In-Reply-To: <20171110154017.GB4196@vimes> References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> <20171110154017.GB4196@vimes> Message-ID: On Fri, Nov 10, 2017 at 4:40 PM, Rob McKenna wrote: > Thanks for the feedback, > > 1) Moving to a single page makes sense, we can always split it up as > necessary if we end up adding to the process docs. > > 2) As David notes the bug approval process will be JBS only, no email > template involved. > > 3) We're sticking with the current codereview practices for a couple of > reasons: > > - Codereview is a contentious issue and out of scope for the updates > project > - Moving to JBS would limit participation to those with JBS logins > - Reviewers are used to monitoring the appropriate email aliases, > introducing a separate process for them to follow would introduce > unnecessary complications > > 4) As noted in the approval page, the public codereview must be > completed prior to requesting critical approval. > > 5) We're setting a higher bar here for update release content. The > process page specifies P1 bugs & serious regressions. If a fix is not > critical then it can likely wait until the next feature release which will > be available within 6 months. (this has the added benefit of incentivizing > users to pick up JDK fixes faster) > > 6) As Phil noted, we're moving to a model where we no longer mandate > that backports need to be fixed in all releases between the next feature > and the backport release. Makes sense, thank you Rob and Phil for the explanation and summary. I still think we should try to leave the door open to non critical but popular backports in updates though. This is especially important for LTS releases, I don't really see anything from this process that requires special casing for the LTS, but if we have a process that does not allow non critical backports we will need to have such special cases for the LTS or come up with a different process. Cheers, Mario From rob.mckenna at oracle.com Fri Nov 10 16:39:07 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 10 Nov 2017 16:39:07 +0000 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> <20171110154017.GB4196@vimes> Message-ID: <20171110163907.GD4196@vimes> Yep, an LTS may require some special casing. Since the first of these is about a year away I'd like to focus on ensuring the process works for the new release cadence for 9u/10u before dealing with LTS specific changes to the project rules. I agree that it is an important conversation that needs to take place once we have a bit more experience with the new release cadence and prior to the first of the LTS releases, perhaps around 6 months or so down the road. -Rob On 10/11/17 17:24, Mario Torre wrote: > On Fri, Nov 10, 2017 at 4:40 PM, Rob McKenna wrote: > > Thanks for the feedback, > > > > 1) Moving to a single page makes sense, we can always split it up as > > necessary if we end up adding to the process docs. > > > > 2) As David notes the bug approval process will be JBS only, no email > > template involved. > > > > 3) We're sticking with the current codereview practices for a couple of > > reasons: > > > > - Codereview is a contentious issue and out of scope for the updates > > project > > - Moving to JBS would limit participation to those with JBS logins > > - Reviewers are used to monitoring the appropriate email aliases, > > introducing a separate process for them to follow would introduce > > unnecessary complications > > > > 4) As noted in the approval page, the public codereview must be > > completed prior to requesting critical approval. > > > > 5) We're setting a higher bar here for update release content. The > > process page specifies P1 bugs & serious regressions. If a fix is not > > critical then it can likely wait until the next feature release which will > > be available within 6 months. (this has the added benefit of incentivizing > > users to pick up JDK fixes faster) > > > > 6) As Phil noted, we're moving to a model where we no longer mandate > > that backports need to be fixed in all releases between the next feature > > and the backport release. > > Makes sense, thank you Rob and Phil for the explanation and summary. > > I still think we should try to leave the door open to non critical but > popular backports in updates though. This is especially important for > LTS releases, I don't really see anything from this process that > requires special casing for the LTS, but if we have a process that > does not allow non critical backports we will need to have such > special cases for the LTS or come up with a different process. > > Cheers, > Mario From goetz.lindenmaier at sap.com Fri Nov 10 16:58:00 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 10 Nov 2017 16:58:00 +0000 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> <0446e21a-972f-98b2-b8a7-140f1bd0b440@oracle.com> <95137423-9478-35a4-e666-f6b0a6b7df18@oracle.com> <20171110154017.GB4196@vimes> Message-ID: <93d3bf4fc24d458ab190832ce46ccdc0@sap.com> Hi, yes, I think too that we need different rules for LTS. We backported the ppc port to 8, and some later the ppc le port. It would be bad if such changes could not be brought to LTS releases. For the short living feature releases backporting only P1 bugs is fine. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev [mailto:jdk-updates-dev-bounces at openjdk.java.net] > On Behalf Of Mario Torre > Sent: Friday, November 10, 2017 5:24 PM > To: Rob McKenna > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: JDK Updates Project Page > > On Fri, Nov 10, 2017 at 4:40 PM, Rob McKenna > wrote: > > Thanks for the feedback, > > > > 1) Moving to a single page makes sense, we can always split it up as > > necessary if we end up adding to the process docs. > > > > 2) As David notes the bug approval process will be JBS only, no email > > template involved. > > > > 3) We're sticking with the current codereview practices for a couple of > > reasons: > > > > - Codereview is a contentious issue and out of scope for the updates > > project > > - Moving to JBS would limit participation to those with JBS logins > > - Reviewers are used to monitoring the appropriate email aliases, > > introducing a separate process for them to follow would introduce > > unnecessary complications > > > > 4) As noted in the approval page, the public codereview must be > > completed prior to requesting critical approval. > > > > 5) We're setting a higher bar here for update release content. The > > process page specifies P1 bugs & serious regressions. If a fix is not > > critical then it can likely wait until the next feature release which will > > be available within 6 months. (this has the added benefit of incentivizing > > users to pick up JDK fixes faster) > > > > 6) As Phil noted, we're moving to a model where we no longer mandate > > that backports need to be fixed in all releases between the next feature > > and the backport release. > > Makes sense, thank you Rob and Phil for the explanation and summary. > > I still think we should try to leave the door open to non critical but > popular backports in updates though. This is especially important for > LTS releases, I don't really see anything from this process that > requires special casing for the LTS, but if we have a process that > does not allow non critical backports we will need to have such > special cases for the LTS or come up with a different process. > > Cheers, > Mario From dalibor.topic at oracle.com Mon Nov 13 08:04:41 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 13 Nov 2017 09:04:41 +0100 Subject: Oracle's plans to contribute to JDK Updates Project in OpenJDK after Java SE 9 End of Public Updates Message-ID: <7a9893ac-76fc-6587-716a-a1c959f6fc53@oracle.com> Hi, Oracle has updated the Oracle Java SE Support Roadmap with a Java SE 9 End of Public Updates Notice. [0] Oracle doesn't plan to contribute further changes to JDK 9 Updates in this OpenJDK Project once updates of Java SE 9 are no longer being posted to its public download site, in March 2018. Instead, Oracle plans to initiate and contribute to the development JDK 10 Updates within this OpenJDK Project in due course. That makes the January 2018 CPU, 9.0.4, the last planned [1] Oracle-led JDK 9 Update release to be developed within this OpenJDK Project. Users of OpenJDK JDK 9 Updates builds should consider upgrading to JDK 10 when it becomes generally available. As with JDK 6 and JDK 7 Updates Projects in the past, if a suitable party steps forward to maintain the JDK 9 Updates series further once the final Oracle-led JDK 9 Update release has been published, we will discuss how to best enable such a transition on this Project's mailing list. cheers, dalibor topic [0] http://www.oracle.com/technetwork/java/eol-135779.html [1] http://openjdk.java.net/projects/jdk-updates/ -- 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 Nov 14 18:47:09 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 14 Nov 2017 18:47:09 +0000 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> Message-ID: On 9 November 2017 at 20:53, Phil Race wrote: > snip... > > > Mario, I think the issue here is that the only planned update releases for > JDK 9 and JDK 10 > are CPU releases. That's the model going forward. And CPU releases only get > absolutely critical fixes .. of which the security fixes are the main > category. > > So there won't be a long tail of 9.0.XXX releases like we had JDK 8 updates > / PSUs > which need these backports. Backports will become increasingly rare. > > Consider that 8u152 had maybe a year of backlogged fixes. > Some fixes we pushed in May (?) to 8u-dev are only just showing up in 8u162 > b01 > for release next year .. > But JDK 10 will be out just 6 months after JDK 9 .. and 9 will then become > obsolete > and unsupported .. so why does it need non-critical backports anyway ? > People should be on 10 by then. > > Backports are going to become rare if I have my facts right. > Well, 8u152 was effectively 8u122 delayed by a year. Prior to that, we were having PSUs in lock-step with CPUs. We've felt this delay a lot in having to backport a pile of fixes from 8u152 locally. I hope the intention with 8u162 is to go back to releasing with the CPU. If so, 8u152 seems more like an anomaly than an example of how we were working before. My expectation would be that the short-lived releases would only really see CPUs but that an LTS would also receive wider updates. Put it this way, it's going to happen somewhere downstream otherwise - I deal with customers wanting backports for issues all the time - and I'd prefer it happened in the OpenJDK repositories so everyone can benefit. > > > >> >> The criticality of the bug may be perceived differently then, >> depending on who is reviewing the fix. I would personally reserve the >> "critical" term for actual really critical issues (a security >> emergency fix for example, or, indeed, a P1 bug), but have another >> flag to signal the backport request, unless the point of this exercise >> is really to not have upstream backport requests any more other than, >> well, critical ones [1]. >> This is something that needs a lot more transparency than the current process. With respect to the 8u122/152 fiasco, I ended up requesting a bunch of bugs we were shipping locally for the CPU, as there was no sign of another PSU any time soon. Some were silently approved and others silently rejected with no explanation. I don't even know who reviewed them and so who was judging whether they were "critical" or not. A fix for AArch64 or PPC may not be critical at all for Oracle, because they don't ship it, but it could be causing regular crashes of the VM and would certainly count as critical for those of us who do ship it. My worry with moving away from the mailing list approach is it decreases the transparency even more. Now only those monitoring the bug will see what's going on. It's also worth noting that not everyone who posts to the update mailing lists has access to the OpenJDK bug database. I've filed bugs and pushed fixes on behalf of others before. -- 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 neugens at redhat.com Wed Nov 15 12:02:13 2017 From: neugens at redhat.com (Mario Torre) Date: Wed, 15 Nov 2017 13:02:13 +0100 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> Message-ID: On Tue, Nov 14, 2017 at 7:47 PM, Andrew Hughes wrote: > My worry with moving away from the mailing list approach is it > decreases the transparency > even more. Now only those monitoring the bug will see what's going on. > It's also worth noting > that not everyone who posts to the update mailing lists has access to > the OpenJDK bug database. > I've filed bugs and pushed fixes on behalf of others before. I actually suggested that to have an all in one place discussion, but Rob mentioned what you say too, that only people with bug database access would be able to participate in the discussion, which is obviously a no-go, the discussion needs to stay open, hence on the mailing list. I think the rules as they stand are pretty ok, for LTS we will need different rules but limiting critical bugs to the short term updates makes sense. We only need to ensure that we can rise bugs to P1 for platforms that are not Oracle main interest, like AArch64 or PPC as you mention or for issues that are not marked as critical by Oracle but are for a given 3rd party. With the short term release, though, keeping a number of patches in downstream builds may be practical to sustain - considering that we are talking about back ports, those fixes will be in upstream repositories already. I wonder if it isn't best to have this conversation again after the 9 and perhaps 10 versions will be EOL to see what is getting accumulated in downstream builds and see if we need a process change to limit the differences. Other than that, I don't see much of a problem, releases are only 6 months away each other, if for some reason 9 is EOLed by Oracle but, just as an example, Red Hat or SAP wants to keep maintaining it, this is the same process as we already do now for 6, 7 and eventually 8, at the take over patches can be merged into the main repository and back ported as newer versions go on for as long as this is needed. Again, the weak link where I expect that to actually happen is the LTS, but this will need a separate set of rules, as we all seem to agree anyway. All that said, you are clearly the most authoritative person regarding back ports issues, if you think something should be changed to facilitate the work with short term releases I think your feedback is really important to have. Cheers, Mario From gnu.andrew at redhat.com Wed Nov 15 16:54:39 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 15 Nov 2017 16:54:39 +0000 Subject: JDK Updates Project Page In-Reply-To: References: <20171106145142.GA3032@vimes> Message-ID: On 15 November 2017 at 12:02, Mario Torre wrote: > On Tue, Nov 14, 2017 at 7:47 PM, Andrew Hughes wrote: > >> My worry with moving away from the mailing list approach is it >> decreases the transparency >> even more. Now only those monitoring the bug will see what's going on. >> It's also worth noting >> that not everyone who posts to the update mailing lists has access to >> the OpenJDK bug database. >> I've filed bugs and pushed fixes on behalf of others before. > > I actually suggested that to have an all in one place discussion, but > Rob mentioned what you say too, that only people with bug database > access would be able to participate in the discussion, which is > obviously a no-go, the discussion needs to stay open, hence on the > mailing list. > > I think the rules as they stand are pretty ok, for LTS we will need > different rules but limiting critical bugs to the short term updates > makes sense. We only need to ensure that we can rise bugs to P1 for > platforms that are not Oracle main interest, like AArch64 or PPC as > you mention or for issues that are not marked as critical by Oracle > but are for a given 3rd party. With the short term release, though, > keeping a number of patches in downstream builds may be practical to > sustain - considering that we are talking about back ports, those > fixes will be in upstream repositories already. > A few patches is inevitable with any project, due to different timelines. The problem with 8u122/152 was that, for example, a fix for GCC 6 I pushed upstream last summer was still not in an upstream release this summer. I think a lot may change as Oracle actually start working on OpenJDK as their release and not a proprietary fork. A lot of my current issues probably stem from this us-vs-them situation where it feels like we're requesting a fix be added to *their* release of *their* JDK, not OpenJDK. These aren't technical issues, but a way of thinking about releases that needs to change. > I wonder if it isn't best to have this conversation again after the 9 > and perhaps 10 versions will be EOL to see what is getting accumulated > in downstream builds and see if we need a process change to limit the > differences. Other than that, I don't see much of a problem, releases > are only 6 months away each other, if for some reason 9 is EOLed by > Oracle but, just as an example, Red Hat or SAP wants to keep > maintaining it, this is the same process as we already do now for 6, 7 > and eventually 8, at the take over patches can be merged into the main > repository and back ported as newer versions go on for as long as this > is needed. > > Again, the weak link where I expect that to actually happen is the > LTS, but this will need a separate set of rules, as we all seem to > agree anyway. > > All that said, you are clearly the most authoritative person regarding > back ports issues, if you think something should be changed to > facilitate the work with short term releases I think your feedback is > really important to have. We will have to see how things progress and what demand there is for various versions. So much is changing that it's hard to know what is best at this point, so the main thing is not to set too much in stone. Based on past experience, I think it's more likely that there will be a demand for LTS releases beyond three years, than for extension of a release that has only been adopted by keen developers wanting the latest and greatest. But unrewarding work like this is based on who will pay for it to be done, so ultimately it depends on these stakeholders. > > Cheers, > Mario Cheers, -- 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