Re: Committer Freebie
Thanks Xuang! On Wed, Jun 14, 2023 at 3:58 PM Lu Xugang wrote: > Hi, Mikhail. I submitted the request about one month ago and got free > access recently. The request does not take effect immediately. > > Xugang > https://www.amazingkoala.com.cn/ > > > Mikhail Khludnev 于2023年6月14日周三 15:37写道： > >> Hello Mark, thanks for the clue. >> Do you know how to promote the request? >> https://github.com/settings/copilot Mine is stuck in request submitted >> state >> >>- [image: @apache]*apache*member >>Request for Copilot for Business submitted. >> >> >> On Tue, Jun 13, 2023 at 1:05 PM Mark Miller >> wrote: >> >>> Purely FYI >>> >>> Figured it’s worth sharing that committers now appear to have free >>> access to GitHub Copilot. >>> >>> Didn’t seem to in the past - I used the free trial, didn’t find it worth >>> paying the 100 bucks for it to be part of my current ecosystem of dev >>> tools, but as I was on my way out, I saw this note that said if you were a >>> committer on a popular GitHub OpenSource project, you got it for free. >>> >>> But it wanted my money. So a couple weeks ago I found some like sales >>> contact form and I wrote some self serving rant about how outrageous the >>> situation was. Common. Then forgot about it and went on. Common. >>> >>> But then I saw in my newsfeed the other day that it went GA or >>> something. I thought I was GA, the waiting list is for CopilotX. They were >>> allowing signups and taking money. So I clicked the news link, and low and >>> behold, it said I didn’t have to pay. So I hope my indignation was the >>> instigator, but probably they expanded the covered projects for this so >>> called GA or something. >>> >>> If it extends to CopilotX, that will be a nice little freebie. >>> >>> Just don’t let Robert catch you with it. Or probably your employer. And >>> it will hilariously pale in comparison to my custom Policeman IntelliJ >>> Plugin that only outputs voice in a stunningly accurate Uwe voice clone, >>> taking no input, just calling out violations in what you are currently >>> working on. >>> >>> But it’s free, 10$ a month value. If it expands to CopilotX, much more >>> value. >>> -- >>> - MRM >>> >> >> >> -- >> Sincerely yours >> Mikhail Khludnev >> > -- Sincerely yours Mikhail Khludnev
Re: Committer Freebie
Hi, Mikhail. I submitted the request about one month ago and got free access recently. The request does not take effect immediately. Xugang https://www.amazingkoala.com.cn/ Mikhail Khludnev 于2023年6月14日周三 15:37写道： > Hello Mark, thanks for the clue. > Do you know how to promote the request? > https://github.com/settings/copilot Mine is stuck in request submitted > state > >- [image: @apache]*apache*member >Request for Copilot for Business submitted. > > > On Tue, Jun 13, 2023 at 1:05 PM Mark Miller wrote: > >> Purely FYI >> >> Figured it’s worth sharing that committers now appear to have free access >> to GitHub Copilot. >> >> Didn’t seem to in the past - I used the free trial, didn’t find it worth >> paying the 100 bucks for it to be part of my current ecosystem of dev >> tools, but as I was on my way out, I saw this note that said if you were a >> committer on a popular GitHub OpenSource project, you got it for free. >> >> But it wanted my money. So a couple weeks ago I found some like sales >> contact form and I wrote some self serving rant about how outrageous the >> situation was. Common. Then forgot about it and went on. Common. >> >> But then I saw in my newsfeed the other day that it went GA or something. >> I thought I was GA, the waiting list is for CopilotX. They were allowing >> signups and taking money. So I clicked the news link, and low and behold, >> it said I didn’t have to pay. So I hope my indignation was the instigator, >> but probably they expanded the covered projects for this so called GA or >> something. >> >> If it extends to CopilotX, that will be a nice little freebie. >> >> Just don’t let Robert catch you with it. Or probably your employer. And >> it will hilariously pale in comparison to my custom Policeman IntelliJ >> Plugin that only outputs voice in a stunningly accurate Uwe voice clone, >> taking no input, just calling out violations in what you are currently >> working on. >> >> But it’s free, 10$ a month value. If it expands to CopilotX, much more >> value. >> -- >> - MRM >> > > > -- > Sincerely yours > Mikhail Khludnev >
Re: JDK 21 is in Rampdown / The importance of testing with Early-Access Builds
Hi, Thanks David! This is perfectly in time also for our release plans. See my previous mails about Project Panama Foreign and Project Panama Vector inclusion in Lucene 9.7. Based on the RDP1, we merged the MMapDirectory and Vector pull requests and will release Lucene 9.7 with support for the new APIs/changed APIs of Java 21. See also announcements on Twitter. We strongly hope that there will be no significant bytecode incompatible changes anymore till release. Please take this into account when you fix bugs in Panama Foreign/Vector: No bytecode incompatible API changes please :-) Thanks, Uwe Am 14.06.2023 um 10:40 schrieb David Delabassee: Welcome to the OpenJDK Quality Outreach June update. JDK 21 has entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 21 stabilization repository. At this point, the overall JDK 21 feature set is frozen. Any changes pushed to the main line are now bound for JDK 22. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. And in contrast to past practice, most stabilization changes will be integrated via backports from the main-line repository [1]. The coming weeks are critical to identify and resolve as many issues as possible, i.e. before JDK 21 enters the Release Candidates phase in August. We need to make sure those few weeks are leveraged to test both existing code running on top of JDK 21 and new JDK 21 features. The heads-up below illustrates the importance and the benefits of doing such tests. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html [2] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements ## Heads-up: On the Importance of Doing Tests With OpenJDK Early-Access Builds The following is a recent example that demonstrates the benefits of testing an existing codebase using the OpenJDK early-access builds. Last month, we published a heads-up focused on Sequenced Collections [3] as they could potentially introduce some incompatibilities. The Eclipse Collections (EC) team did their homework and sure enough, EC was impacted as it was now throwing compilation errors with JDK 21 early-access builds. The EC team was able to quickly fix those compilation errors, i.e., it was mainly about adding overriding default methods. But once those compilation errors were fixed, and this is where it gets interesting, another issue surfaced. This time, the problem was related to LinkedHashMap serialization. After some investigation, the EC team identified that second issue as JDK one and a JBS ticket was opened. That issue was then confirmed as a JDK regression and was promptly fixed in OpenJDK main-line, i.e., JDK 22. The fix was then backported into the JDK 21 stabilization repository. This EC pull request [4] provides additional details. In this case, the JDK fix was easy but it is nevertheless the kind of issues that could have easily fallen through the crack if the EC team wasn’t pro-actively testing with OpenJDK early-access builds. The EC issue would have then surfaced after the JDK 21 General Availability... and who knows when the JDK LinkedHashMap serialization regression would have been fixed? TL; DR; Testing an existing codebase with OpenJDK early-access builds is a win-win situation. It helps the project itself, Eclipse Collections in this case, as it enables developers to identify issues in their own codebase before that new JDK version is Generally Available. It helps the JDK too as any JDK issue detected early enough in the development cycle gives the OpenJDK engineers a chance to address it before the General Availability of that new JDK version. And last but not least, having a robust JDK is also a win for the Java community at large. And thanks to the Eclipse Collections team and especially to Don Raab for helping to make the Java platform more robust! [3] https://inside.java/2023/05/12/quality-heads-up/ [4] https://github.com/eclipse/eclipse-collections/pull/1461 ## JDK 21 Early-Access Builds JDK 21 Early-Access builds 26 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6] and the javadocs here [7]. ### JEPs integrated into JDK 21: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 440: Record Patterns - 441: Pattern Matching for switch - 442: Foreign Function & Memory API (3rd Preview) - 443: Unnamed Patterns and Variables (Preview) - 444: Virtual Threads - 445: Unnamed Classes and Instance Main Methods (Preview) - 446: Scoped Values (Preview) - 448: Vector API (6th Incubator) - 449: Deprecate the Windows 32-bit x86 Port for Removal - 451: Prepare to Disallow the Dynamic Loading of Agents - 452: Key Encapsulation Mechanism API - 453: Structured Concurrency (Preview)
JDK 21 is in Rampdown / The importance of testing with Early-Access Builds
Welcome to the OpenJDK Quality Outreach June update. JDK 21 has entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 21 stabilization repository. At this point, the overall JDK 21 feature set is frozen. Any changes pushed to the main line are now bound for JDK 22. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. And in contrast to past practice, most stabilization changes will be integrated via backports from the main-line repository [1]. The coming weeks are critical to identify and resolve as many issues as possible, i.e. before JDK 21 enters the Release Candidates phase in August. We need to make sure those few weeks are leveraged to test both existing code running on top of JDK 21 and new JDK 21 features. The heads-up below illustrates the importance and the benefits of doing such tests. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html [2] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements ## Heads-up: On the Importance of Doing Tests With OpenJDK Early-Access Builds The following is a recent example that demonstrates the benefits of testing an existing codebase using the OpenJDK early-access builds. Last month, we published a heads-up focused on Sequenced Collections [3] as they could potentially introduce some incompatibilities. The Eclipse Collections (EC) team did their homework and sure enough, EC was impacted as it was now throwing compilation errors with JDK 21 early-access builds. The EC team was able to quickly fix those compilation errors, i.e., it was mainly about adding overriding default methods. But once those compilation errors were fixed, and this is where it gets interesting, another issue surfaced. This time, the problem was related to LinkedHashMap serialization. After some investigation, the EC team identified that second issue as JDK one and a JBS ticket was opened. That issue was then confirmed as a JDK regression and was promptly fixed in OpenJDK main-line, i.e., JDK 22. The fix was then backported into the JDK 21 stabilization repository. This EC pull request [4] provides additional details. In this case, the JDK fix was easy but it is nevertheless the kind of issues that could have easily fallen through the crack if the EC team wasn’t pro-actively testing with OpenJDK early-access builds. The EC issue would have then surfaced after the JDK 21 General Availability... and who knows when the JDK LinkedHashMap serialization regression would have been fixed? TL; DR; Testing an existing codebase with OpenJDK early-access builds is a win-win situation. It helps the project itself, Eclipse Collections in this case, as it enables developers to identify issues in their own codebase before that new JDK version is Generally Available. It helps the JDK too as any JDK issue detected early enough in the development cycle gives the OpenJDK engineers a chance to address it before the General Availability of that new JDK version. And last but not least, having a robust JDK is also a win for the Java community at large. And thanks to the Eclipse Collections team and especially to Don Raab for helping to make the Java platform more robust! [3] https://inside.java/2023/05/12/quality-heads-up/ [4] https://github.com/eclipse/eclipse-collections/pull/1461 ## JDK 21 Early-Access Builds JDK 21 Early-Access builds 26 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6] and the javadocs here [7]. ### JEPs integrated into JDK 21: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 440: Record Patterns - 441: Pattern Matching for switch - 442: Foreign Function & Memory API (3rd Preview) - 443: Unnamed Patterns and Variables (Preview) - 444: Virtual Threads - 445: Unnamed Classes and Instance Main Methods (Preview) - 446: Scoped Values (Preview) - 448: Vector API (6th Incubator) - 449: Deprecate the Windows 32-bit x86 Port for Removal - 451: Prepare to Disallow the Dynamic Loading of Agents - 452: Key Encapsulation Mechanism API - 453: Structured Concurrency (Preview) It is worth mentioning that JEP 404 (Generational Shenandoah - Experimental) has been proposed to drop from JDK 21 [8]. ### Changes in recent JDK 21 builds (b23-b26) that may be of interest: Note that this is only a curated list of changes, make sure to check [9] for additional changes. - JDK-8298127: HSS/LMS Signature Verification - JDK-8305972: Update XML Security for Java to 3.0.2 - JDK-8308244: Installation of jdk rpm corrupts alternatives - JDK-8307990: jspawnhelper must close its writing side of a pipe before reading from it - JDK-8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates - JDK-8303530: Redefine JAXP Configuration File -
Re: Committer Freebie
Hello Mark, thanks for the clue. Do you know how to promote the request? https://github.com/settings/copilot Mine is stuck in request submitted state - [image: @apache]*apache*member Request for Copilot for Business submitted. On Tue, Jun 13, 2023 at 1:05 PM Mark Miller wrote: > Purely FYI > > Figured it’s worth sharing that committers now appear to have free access > to GitHub Copilot. > > Didn’t seem to in the past - I used the free trial, didn’t find it worth > paying the 100 bucks for it to be part of my current ecosystem of dev > tools, but as I was on my way out, I saw this note that said if you were a > committer on a popular GitHub OpenSource project, you got it for free. > > But it wanted my money. So a couple weeks ago I found some like sales > contact form and I wrote some self serving rant about how outrageous the > situation was. Common. Then forgot about it and went on. Common. > > But then I saw in my newsfeed the other day that it went GA or something. > I thought I was GA, the waiting list is for CopilotX. They were allowing > signups and taking money. So I clicked the news link, and low and behold, > it said I didn’t have to pay. So I hope my indignation was the instigator, > but probably they expanded the covered projects for this so called GA or > something. > > If it extends to CopilotX, that will be a nice little freebie. > > Just don’t let Robert catch you with it. Or probably your employer. And it > will hilariously pale in comparison to my custom Policeman IntelliJ Plugin > that only outputs voice in a stunningly accurate Uwe voice clone, taking no > input, just calling out violations in what you are currently working on. > > But it’s free, 10$ a month value. If it expands to CopilotX, much more > value. > -- > - MRM > -- Sincerely yours Mikhail Khludnev
