From smarks at openjdk.java.net Tue Aug 10 23:51:35 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 10 Aug 2021 23:51:35 GMT Subject: RFR: Section about the release process [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 23:23:29 GMT, Jesper Wilhelmsson wrote: >> Answering some common questions around the release process. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Fixed typos Changes requested by smarks (Author). src/index.md line 1719: > 1717: > 1718: [**The start of a release**]{#release-start} > 1719: : Since development is always ongoing in the mainline repository ([openjdk/jdk](https://github.com/openjdk/jdk)), the start of a new release can be said to begin when the former release is forked of from mainline. After the start of the release follows six months of development to implement and integrate all the cool stuff that will go into the next release. After these six months rampdown begins. wording: probably "forked from the mainline" at the end of the first sentence. src/index.md line 1725: > 1723: > 1724: [**Ramp Down Phase 1 (RDP1)**]{#rdp1} > 1725: : At RDS we enter RDP1. During this phase you may continue to fix P1-P3 product bugs. P4 and P5 product bugs should be deferred at this point. Test bugs (labeled `noreg-self`) and documentation bugs (labeled `noreg-doc`) can still be fixed in RDP1 regardless of their priority. To fix an enhancement an approval is required. See the [Late-Enhancement Request Process](https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process) for details on how to do that. If you want to defer a P1 or P2 bug during RDP1 you will also need an approval. See the [Bug-Deferral Process](https://openjdk.java.net/jeps/3#Bug-Deferral-Process) for more details. It would be good to avoid duplication with JEP 3. Some of the text here seems to do that, such as late enhancements and bug deferrals. By contrast, the discussion in the previous section about when to put features into a release is indeed suitable for the Guide. I'm not familiar with "RDS". It's not mentioned anywhere in JEP 3, nor have I heard it much in our discussions. Can't we just say that the mainline repository is forked at the beginning of RDP1, and the new rules apply to the stabilization repo? src/index.md line 1728: > 1726: > 1727: [**Feature Complete (FC)**]{#fc} > 1728: : Feature Complete is declared when all features that are supposed to be in the release have been integrated into the release. With the six-month release cadence, FC is defined as a date rather than a set of features, so the features that are integrated by FC are the features that should be in the release. FC is normally the same day as RDS. I'm not sure talking about "Feature Complete" is helpful. In projects that are feature-driven, "feature complete" means "we've completed all the features that have been committed for this release". That clearly doesn't apply here. So then you have to explain that it means something different. It doesn't seem to be a separate phase or milestone. The feature set is frozen at the beginning of RDP1 (with some exceptions permitted, namely, the late-enhancement requests). Put another way, the deadline for integrating JEPs and enhancements is the beginning of RDP1. src/index.md line 1753: > 1751: | RDP1 | Fix or Defer with approval | Fix or Defer with approval | Fix or Defer | Defer | Fix or Defer | Fix with approval or Defer | > 1752: | RDP2 | Fix with approval or Defer with approval | Fix with approval or Defer with approval | Defer | Defer | Fix or Defer | Defer | > 1753: | RC | Fix with approval or Defer with approval | Defer | Defer | Defer | Defer | Defer | Is this table the same as in JEP 3? src/index.md line 1759: > 1757: During the rampdown of a release there are two repositories in play, the stabilization fork for the outgoing release, and the mainline repository where the next release is being developed. Any bugfix going into the stabilization fork is likely to be desired in mainline as well. As a developer you should push your fix to the stabilization fork **only**, even if you intend for it to go to both repositories. Your fix will be forward ported to mainline. > 1758: > 1759: All fixes that are pushed to the stabilization fork are forward ported to mainline. If you have a fix that is only intended for the stabilization fork you will have to manually back it out from mainline once it has been forward ported. Is this the way it really works? Certainly every commit is pulled from the stabilization fork into the mainline, since we want the mainline to include all the commits from the previous release. But are all those commits necessarily merged onto the master branch? Offhand I can't think of a better way, but maybe this deserves more discussion. At the very least, maybe there needs to be some workflow. For example, if you want to fix JDK-xxx in the stabilization fork but not in the mainline, you need to file JDK-yyy to back out the fix after it's merged into the mainline, and then link the bugs together in a particular way, or something. ------------- PR: https://git.openjdk.java.net/guide/pull/62 From smarks at openjdk.java.net Wed Aug 11 00:04:32 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 11 Aug 2021 00:04:32 GMT Subject: RFR: Roles in the OpenJDK [v4] In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 13:56:10 GMT, Jesper Wilhelmsson wrote: >> Added a short intro about OpenJDK describing Groups, Projects, and different roles. The sections on how to progress through the Author, Committer, Reviewer roles needs a broad agreement since that's an area that affects everyone and where there historically has been a lot of debate. This is a first draft, please comment. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > one of A couple typos/spelling issues, maybe a bit of editorial suggestions. Updates can be done as part of this PR or in a later one, at your option. src/index.md line 26: > 24: ::: > 25: > 26: OpenJDK consists of a number of [Groups](https://openjdk.java.net/groups/). Members of a group collaborates on an area of mutual interest. The right hand side bar on the [OpenJDK website](https://openjdk.java.net/) has a list of all groups in OpenJDK. If you're interested in a specific area, this is where you would start your OpenJDK experience. Look at the group's information and wiki pages, and see what projects they sponsor on the [Census page](https://openjdk.java.net/census). collaborates => collaborate src/index.md line 34: > 32: OpenJDK has a few different roles that determine who has the right to do what in the different projects. These roles are defined in the [OpenJDK Bylaws](https://openjdk.java.net/bylaws#project-roles). The roles are earned based on experience and knowledge within each project. > 33: > 34: A Contributor can have different roles in different projects. When you're new to a project you don't yet have a formal role in that specific project, even though you might have earned roles in other OpenJDK projects or have been recognized as a [Contributor](https://openjdk.java.net/bylaws#contributor) or a [Member](https://openjdk.java.net/bylaws#openjdk-member) of OpenJDK. By contributing high-quality content you'll soon be eligible for [OpenJDK roles](https://openjdk.java.net/bylaws#project-roles) in the project. First [Author](https://openjdk.java.net/bylaws#author), then [Committer](https://openjdk.java.net/bylaws#committer), and finally [Reviewer](https://openjdk.java.net/bylaws#reviewer) if you stay active and earn the trust of the community. Trust is an important part of earning these roles. There's a [rough guideline](https://openjdk.java.net/projects/) saying that to become a [Committer](https://openjdk.java.net/bylaws#committer) you should have contributed 8 signific ant changes, and to become a [Reviewer](https://openjdk.java.net/bylaws#reviewer) you should have contributed 32 significant changes. In reality it's not as easy as "just" contributing code. You need to build a track record of good decisions and sound judgement and show that you know what differentiates a good change from a not so good one. It's not only correctness of the code that matters, it's also the appropriateness. In the end the trust you've earned is put to the test through a vote. judgement => judgment although this might be a difference between American and British spelling, up to you. If you want to use "judgement" throughout that's ok with me (I saw it in at least one other place). src/index.md line 40: > 38: Becoming an [Author](https://openjdk.java.net/bylaws#author) is the first step. To achieve this you need to contribute two non-trivial changes to the project in which you wish to become an Author. Once your changes are pushed into the code base and has been vetted enough to determine that the changes were indeed good changes you can go ahead and send an email to the project lead of that particular project and ask to be added as an Author. > 39: > 40: As an Author you have the formal right to produce changesets for inclusion into the projects code base, but you will need a sponsor to perform the actual push. You'll also have write access to [JBS](#jbs---jdk-bug-system). I think as an author you also have edit access to the wiki. src/index.md line 44: > 42: ### Becoming a Committer > 43: > 44: To become a [Committer](https://openjdk.java.net/bylaws#committer) you should show that you can produce non-trivial changes that are accepted for inclusion into the project code base. The number eight has been seen as a formal lower limit on the number of changes, but since the changes must be non-trivial, or "significant" as the [OpenJDK Project description](https://openjdk.java.net/projects/) says, and the definition of significant is extremely subjective, the general recommendation is to wait with a Committer nomination until there's at least 10-12 changes pushed to have some margin for different interpretations of "significant". I wouldn't say "extremely subjective" but I would agree that it is subjective. It's probably wise to have a few extra commits over the required 8 in case there is some difference of opinion. I think some advice to add here is to seek out a sponsor who will guide you through the process to becoming a Committer. This person might have actually sponsored some commits you developed as an Author. This person would also be responsible for running your Committer vote. They probably will have a better idea of what constitutes a "significant" change. src/index.md line 67: > 65: * Repeated follow-up bugfixes from earlier changes > 66: * Larger changes where only a non-significant portion of the work was done by the Contributor under vote > 67: * Trivial backports of someone else's changes Maybe this section belongs in the Committer section? I think it's really the only place where the significance of a commit comes into play. src/index.md line 77: > 75: If you have a success story where Java solved your problem, or if you successfully upgraded to a more recent version of the JDK and noticed some improvements, spreading this story through a blog, news article, or some other channel is also a contribution. > 76: > 77: If you're in a position to choose what programming language to use in a project, in a tutorial, or in a class, you have the power to enlarge the Java community in a very direct way, and your colleagues or students will get an opportunity to learn one of the most used programming languages in the world. This is a good section, talking about contributions in general, not just code like everybody thinks it is. One thing I'd suggest adding is finding and diagnosing bugs. If you see some misbehavior, or if you see somebody mention some misbehavior on some internet forum, try to track it down. Good bug reports with reproducible test cases are extremely valuable and make excellent contributions. ------------- Marked as reviewed by smarks (Author). PR: https://git.openjdk.java.net/guide/pull/60 From smarks at openjdk.java.net Wed Aug 11 00:13:37 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 11 Aug 2021 00:13:37 GMT Subject: RFR: Section on cloning [v2] In-Reply-To: References: Message-ID: <1WRuP4yzJM1B_OmClef_sAtaL04ivqhwnW_CoJWLN3o=.12fc58aa-9316-4836-b523-ad3f14c84f4f@github.com> On Wed, 23 Jun 2021 00:17:11 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Moved SSH key section Marked as reviewed by smarks (Author). src/index.md line 1001: > 999: $ git remote add upstream git at github.com:openjdk/jdk.git > 1000: > 1001: In the example above I cloned my personal fork of the JDK mainline repository. You should of course use your own GitHub username instead. Then, by adding a new *remote* named 'upstream', we associate this clone with [openjdk/jdk](https://github.com/openjdk/jdk) as well. Doing this will allow the tooling to automatically create a PR request on [openjdk/jdk](https://github.com/openjdk/jdk) whenever you push a change to your personal fork. The way that works is that once you have pushed a change to your private fork, and navigate to the [openjdk/jdk](https://github.com/openjdk/jdk) repository on GitHub, there will be a message saying that you just pushed a change and asking if you want to create a PR. "PR request" => "PR" src/index.md line 1006: > 1004: > 1005: $ git checkout master > 1006: $ git checkout -b my-fix I'm not sure whether we should recomment "git checkout -b" or "git switch -c". I think switch is safer, but the doc says that it's experimental.... src/index.md line 1050: > 1048: * Click "Add SSH key" > 1049: > 1050: Now you are ready to clone your [openjdk/jdk](https://github.com/openjdk/jdk) fork using SSH. I suspect this SSH stuff is all fine for Linux and Mac. What about Windows? I imagine that one would need to install OpenSSH or something before this will work. I haven't done this though. src/index.md line 1082: > 1080: $ curl https://download.java.net/java/GA/jdk16.0.1/7147401fd7354114ac51ef3e1328291f/9/GPL/openjdk-16.0.1_osx-x64_bin.tar.gz --output openjdk-16.0.1_osx-x64_bin.tar.gz > 1081: $ tar xzf openjdk-16.0.1_osx-x64_bin.tar.gz > 1082: $ # Get XCode from Appstore I think this should be a separate text paragraph, not a comment in what looks like a cookbook script to building the JDK. Getting XCode is kind of a problem. You can get it from the App Store; but sometimes the App Store version is too new for the OS version you have, so you have to get an older XCode. But of course if XCode is too old then it can't build the JDK. Obviously we can't write a whole section that covers all these issues. Plus, it changes from time to time as Apple releases new versions of things. I'd suggest having a separate paragraph that talks about getting XCode from the App Store, or the possible need to get older versions from Apple's developer site. I would avoid putting too many details in this document. Probably the best fallback is to tell people to ask on the mailing list if they have trouble with this step. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Wed Aug 11 23:52:02 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 11 Aug 2021 23:52:02 GMT Subject: RFR: Section about the release process [v2] In-Reply-To: References: Message-ID: <7aZ2zZJf8i819q6sc3Ue2JM6g3d_sAv9E1ao4421bkg=.d6ef9903-3f81-46c5-9b93-1012d2f5d73d@github.com> On Tue, 10 Aug 2021 23:36:22 GMT, Stuart Marks wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typos > > src/index.md line 1719: > >> 1717: >> 1718: [**The start of a release**]{#release-start} >> 1719: : Since development is always ongoing in the mainline repository ([openjdk/jdk](https://github.com/openjdk/jdk)), the start of a new release can be said to begin when the former release is forked of from mainline. After the start of the release follows six months of development to implement and integrate all the cool stuff that will go into the next release. After these six months rampdown begins. > > wording: probably "forked from the mainline" at the end of the first sentence. Fixed > src/index.md line 1725: > >> 1723: >> 1724: [**Ramp Down Phase 1 (RDP1)**]{#rdp1} >> 1725: : At RDS we enter RDP1. During this phase you may continue to fix P1-P3 product bugs. P4 and P5 product bugs should be deferred at this point. Test bugs (labeled `noreg-self`) and documentation bugs (labeled `noreg-doc`) can still be fixed in RDP1 regardless of their priority. To fix an enhancement an approval is required. See the [Late-Enhancement Request Process](https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process) for details on how to do that. If you want to defer a P1 or P2 bug during RDP1 you will also need an approval. See the [Bug-Deferral Process](https://openjdk.java.net/jeps/3#Bug-Deferral-Process) for more details. > > It would be good to avoid duplication with JEP 3. Some of the text here seems to do that, such as late enhancements and bug deferrals. By contrast, the discussion in the previous section about when to put features into a release is indeed suitable for the Guide. > > I'm not familiar with "RDS". It's not mentioned anywhere in JEP 3, nor have I heard it much in our discussions. Can't we just say that the mainline repository is forked at the beginning of RDP1, and the new rules apply to the stabilization repo? I removed RDS and reworked RDP1. Now referring to JEP 3 instead of repeating all the details. > src/index.md line 1728: > >> 1726: >> 1727: [**Feature Complete (FC)**]{#fc} >> 1728: : Feature Complete is declared when all features that are supposed to be in the release have been integrated into the release. With the six-month release cadence, FC is defined as a date rather than a set of features, so the features that are integrated by FC are the features that should be in the release. FC is normally the same day as RDS. > > I'm not sure talking about "Feature Complete" is helpful. In projects that are feature-driven, "feature complete" means "we've completed all the features that have been committed for this release". That clearly doesn't apply here. So then you have to explain that it means something different. It doesn't seem to be a separate phase or milestone. The feature set is frozen at the beginning of RDP1 (with some exceptions permitted, namely, the late-enhancement requests). Put another way, the deadline for integrating JEPs and enhancements is the beginning of RDP1. I removed FC. ------------- PR: https://git.openjdk.java.net/guide/pull/62 From jwilhelm at openjdk.java.net Wed Aug 11 23:51:55 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 11 Aug 2021 23:51:55 GMT Subject: RFR: Section about the release process [v3] In-Reply-To: References: Message-ID: > Answering some common questions around the release process. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Updates after review ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/62/files - new: https://git.openjdk.java.net/guide/pull/62/files/4db373f0..32bf9285 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=62&range=02 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=62&range=01-02 Stats: 27 lines in 1 file changed: 2 ins; 13 del; 12 mod Patch: https://git.openjdk.java.net/guide/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/62/head:pull/62 PR: https://git.openjdk.java.net/guide/pull/62 From jwilhelm at openjdk.java.net Wed Aug 11 23:57:34 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 11 Aug 2021 23:57:34 GMT Subject: RFR: Section about the release process [v2] In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 23:43:28 GMT, Stuart Marks wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typos > > src/index.md line 1753: > >> 1751: | RDP1 | Fix or Defer with approval | Fix or Defer with approval | Fix or Defer | Defer | Fix or Defer | Fix with approval or Defer | >> 1752: | RDP2 | Fix with approval or Defer with approval | Fix with approval or Defer with approval | Defer | Defer | Fix or Defer | Defer | >> 1753: | RC | Fix with approval or Defer with approval | Defer | Defer | Defer | Defer | Defer | > > Is this table the same as in JEP 3? I was never happy with the table. I think the table in JEP 3 is difficult to read but this wasn't any better. I removed the table. I think some other (graphical) picture is needed to clarify what can be pushed and deferred when. > src/index.md line 1759: > >> 1757: During the rampdown of a release there are two repositories in play, the stabilization fork for the outgoing release, and the mainline repository where the next release is being developed. Any bugfix going into the stabilization fork is likely to be desired in mainline as well. As a developer you should push your fix to the stabilization fork **only**, even if you intend for it to go to both repositories. Your fix will be forward ported to mainline. >> 1758: >> 1759: All fixes that are pushed to the stabilization fork are forward ported to mainline. If you have a fix that is only intended for the stabilization fork you will have to manually back it out from mainline once it has been forward ported. > > Is this the way it really works? Certainly every commit is pulled from the stabilization fork into the mainline, since we want the mainline to include all the commits from the previous release. But are all those commits necessarily merged onto the master branch? Offhand I can't think of a better way, but maybe this deserves more discussion. At the very least, maybe there needs to be some workflow. For example, if you want to fix JDK-xxx in the stabilization fork but not in the mainline, you need to file JDK-yyy to back out the fix after it's merged into the mainline, and then link the bugs together in a particular way, or something. This is the way it works. I forward port all changes from JDK 17 to mainline, and if a change is not for mainline it must be backed out. I added a paragraph with your example to clarify the JBS part. ------------- PR: https://git.openjdk.java.net/guide/pull/62 From smarks at openjdk.java.net Thu Aug 12 00:45:32 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 12 Aug 2021 00:45:32 GMT Subject: RFR: Section about the release process [v3] In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 23:51:55 GMT, Jesper Wilhelmsson wrote: >> Answering some common questions around the release process. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Updates after review Marked as reviewed by smarks (Author). Updated changes all look good, thanks. ------------- PR: https://git.openjdk.java.net/guide/pull/62 From smarks at openjdk.java.net Thu Aug 12 00:45:32 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 12 Aug 2021 00:45:32 GMT Subject: RFR: Section about the release process [v2] In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 23:54:21 GMT, Jesper Wilhelmsson wrote: >> src/index.md line 1759: >> >>> 1757: During the rampdown of a release there are two repositories in play, the stabilization fork for the outgoing release, and the mainline repository where the next release is being developed. Any bugfix going into the stabilization fork is likely to be desired in mainline as well. As a developer you should push your fix to the stabilization fork **only**, even if you intend for it to go to both repositories. Your fix will be forward ported to mainline. >>> 1758: >>> 1759: All fixes that are pushed to the stabilization fork are forward ported to mainline. If you have a fix that is only intended for the stabilization fork you will have to manually back it out from mainline once it has been forward ported. >> >> Is this the way it really works? Certainly every commit is pulled from the stabilization fork into the mainline, since we want the mainline to include all the commits from the previous release. But are all those commits necessarily merged onto the master branch? Offhand I can't think of a better way, but maybe this deserves more discussion. At the very least, maybe there needs to be some workflow. For example, if you want to fix JDK-xxx in the stabilization fork but not in the mainline, you need to file JDK-yyy to back out the fix after it's merged into the mainline, and then link the bugs together in a particular way, or something. > > This is the way it works. I forward port all changes from JDK 17 to mainline, and if a change is not for mainline it must be backed out. I added a paragraph with your example to clarify the JBS part. OK. If this is the way it really works, then clearly that reality needs to be documented. I'm a bit surprised about this; on the other hand, I thought of several alternatives, but they're either unworkable or more complicated and don't offer any advantages. This is probably a pretty rare case, so maybe the workflow is fine as it stands. The filing-two-bugs material looks reasonable. I might strengthen it to say something like the following. ? As soon as you know that there is a fix that needs to go into the stabilization fork but not the mainline, you should do the following: file a bug JDK-yyy to cover the backout work, link it to JDK-xxx, set its Fix Version to the next release, add a comment describing the situation, and set the priority to be relatively high (e.g., P3). Then, you have to wait until the JDK-xxx fix is forward ported to the mainline before actually fixing JDK-yyy. Making these settings in JDK-yyy will help ensure that it won't be missed. ? ------------- PR: https://git.openjdk.java.net/guide/pull/62 From jwilhelm at openjdk.java.net Thu Aug 12 01:03:03 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 01:03:03 GMT Subject: RFR: Roles in the OpenJDK [v4] In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 00:01:57 GMT, Stuart Marks wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> one of > > A couple typos/spelling issues, maybe a bit of editorial suggestions. Updates can be done as part of this PR or in a later one, at your option. Thank you for your review @stuart-marks > src/index.md line 26: > >> 24: ::: >> 25: >> 26: OpenJDK consists of a number of [Groups](https://openjdk.java.net/groups/). Members of a group collaborates on an area of mutual interest. The right hand side bar on the [OpenJDK website](https://openjdk.java.net/) has a list of all groups in OpenJDK. If you're interested in a specific area, this is where you would start your OpenJDK experience. Look at the group's information and wiki pages, and see what projects they sponsor on the [Census page](https://openjdk.java.net/census). > > collaborates => collaborate Fixed. > src/index.md line 34: > >> 32: OpenJDK has a few different roles that determine who has the right to do what in the different projects. These roles are defined in the [OpenJDK Bylaws](https://openjdk.java.net/bylaws#project-roles). The roles are earned based on experience and knowledge within each project. >> 33: >> 34: A Contributor can have different roles in different projects. When you're new to a project you don't yet have a formal role in that specific project, even though you might have earned roles in other OpenJDK projects or have been recognized as a [Contributor](https://openjdk.java.net/bylaws#contributor) or a [Member](https://openjdk.java.net/bylaws#openjdk-member) of OpenJDK. By contributing high-quality content you'll soon be eligible for [OpenJDK roles](https://openjdk.java.net/bylaws#project-roles) in the project. First [Author](https://openjdk.java.net/bylaws#author), then [Committer](https://openjdk.java.net/bylaws#committer), and finally [Reviewer](https://openjdk.java.net/bylaws#reviewer) if you stay active and earn the trust of the community. Trust is an important part of earning these roles. There's a [rough guideline](https://openjdk.java.net/projects/) saying that to become a [Committer](https://openjdk.java.net/bylaws#committer) you should have contributed 8 signifi cant changes, and to become a [Reviewer](https://openjdk.java.net/bylaws#reviewer) you should have contributed 32 significant changes. In reality it's not as easy as "just" contributing code. You need to build a track record of good decisions and sound judgement and show that you know what differentiates a good change from a not so good one. It's not only correctness of the code that matters, it's also the appropriateness. In the end the trust you've earned is put to the test through a vote. > > judgement => judgment > > although this might be a difference between American and British spelling, up to you. If you want to use "judgement" throughout that's ok with me (I saw it in at least one other place). Judgment is the most common spelling in both American and British English. I have changed all occurrences. > src/index.md line 40: > >> 38: Becoming an [Author](https://openjdk.java.net/bylaws#author) is the first step. To achieve this you need to contribute two non-trivial changes to the project in which you wish to become an Author. Once your changes are pushed into the code base and has been vetted enough to determine that the changes were indeed good changes you can go ahead and send an email to the project lead of that particular project and ask to be added as an Author. >> 39: >> 40: As an Author you have the formal right to produce changesets for inclusion into the projects code base, but you will need a sponsor to perform the actual push. You'll also have write access to [JBS](#jbs---jdk-bug-system). > > I think as an author you also have edit access to the wiki. Added the wiki as well. > src/index.md line 44: > >> 42: ### Becoming a Committer >> 43: >> 44: To become a [Committer](https://openjdk.java.net/bylaws#committer) you should show that you can produce non-trivial changes that are accepted for inclusion into the project code base. The number eight has been seen as a formal lower limit on the number of changes, but since the changes must be non-trivial, or "significant" as the [OpenJDK Project description](https://openjdk.java.net/projects/) says, and the definition of significant is extremely subjective, the general recommendation is to wait with a Committer nomination until there's at least 10-12 changes pushed to have some margin for different interpretations of "significant". > > I wouldn't say "extremely subjective" but I would agree that it is subjective. It's probably wise to have a few extra commits over the required 8 in case there is some difference of opinion. I think some advice to add here is to seek out a sponsor who will guide you through the process to becoming a Committer. This person might have actually sponsored some commits you developed as an Author. This person would also be responsible for running your Committer vote. They probably will have a better idea of what constitutes a "significant" change. I've added some wording on seeking the advice from a sponsor. > src/index.md line 67: > >> 65: * Repeated follow-up bugfixes from earlier changes >> 66: * Larger changes where only a non-significant portion of the work was done by the Contributor under vote >> 67: * Trivial backports of someone else's changes > > Maybe this section belongs in the Committer section? I think it's really the only place where the significance of a commit comes into play. The word "significant" is used in the description of the 32 changes required for the Reviewer role as well. I agree that the significance of the commits are of less importance in the Reviewer case and I intended for the text to show that there are other criteria that are more important. I would prefer to keep this section where it is. I see it as kind of a foot-note and I think it would take too much space if placed in the Committer section. I assume that you noted that it's not in the Reviewer section, it's below the Reviewer section. That may not be obvious when looking at the markdown. > src/index.md line 77: > >> 75: If you have a success story where Java solved your problem, or if you successfully upgraded to a more recent version of the JDK and noticed some improvements, spreading this story through a blog, news article, or some other channel is also a contribution. >> 76: >> 77: If you're in a position to choose what programming language to use in a project, in a tutorial, or in a class, you have the power to enlarge the Java community in a very direct way, and your colleagues or students will get an opportunity to learn one of the most used programming languages in the world. > > This is a good section, talking about contributions in general, not just code like everybody thinks it is. > > One thing I'd suggest adding is finding and diagnosing bugs. If you see some misbehavior, or if you see somebody mention some misbehavior on some internet forum, try to track it down. Good bug reports with reproducible test cases are extremely valuable and make excellent contributions. Added your suggestion. ------------- PR: https://git.openjdk.java.net/guide/pull/60 From jwilhelm at openjdk.java.net Thu Aug 12 01:02:53 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 01:02:53 GMT Subject: RFR: Roles in the OpenJDK [v5] In-Reply-To: References: Message-ID: <1NVlNrSjAs-8TQXPbCLIoS4SCJKiwIY4ub3zvkLH19k=.90f8452e-643e-4e99-8805-a502c99558b7@github.com> > Added a short intro about OpenJDK describing Groups, Projects, and different roles. The sections on how to progress through the Author, Committer, Reviewer roles needs a broad agreement since that's an area that affects everyone and where there historically has been a lot of debate. This is a first draft, please comment. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Updated after review. ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/60/files - new: https://git.openjdk.java.net/guide/pull/60/files/81ab5dca..a6de4771 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=60&range=04 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=60&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/guide/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/60/head:pull/60 PR: https://git.openjdk.java.net/guide/pull/60 From jwilhelm at openjdk.java.net Thu Aug 12 01:05:35 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 01:05:35 GMT Subject: RFR: Section about the release process [v3] In-Reply-To: References: Message-ID: <7E_u-fg8MQzOqnzanoDxwoBjcqz9lBkz-nhx_IFg5Oc=.ee676653-f123-4b70-af36-84abd6209539@github.com> On Thu, 12 Aug 2021 00:42:46 GMT, Stuart Marks wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates after review > > Updated changes all look good, thanks. Thank you for your reviews @stuart-marks! ------------- PR: https://git.openjdk.java.net/guide/pull/62 From jwilhelm at openjdk.java.net Thu Aug 12 19:27:56 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 19:27:56 GMT Subject: RFR: Section on cloning [v3] In-Reply-To: References: Message-ID: <-AdCI1xrnXbHnD63Z7s_h7OnaS9Qbe6AHhmRVCK6xh0=.5b9a2d25-46db-46d9-826a-644ad22fc2b4@github.com> > Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Updates after review ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/59/files - new: https://git.openjdk.java.net/guide/pull/59/files/69d23dd6..7afd9c76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=02 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=01-02 Stats: 12 lines in 1 file changed: 1 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/guide/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/59/head:pull/59 PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 19:30:38 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 19:30:38 GMT Subject: RFR: Section on cloning [v2] In-Reply-To: <1WRuP4yzJM1B_OmClef_sAtaL04ivqhwnW_CoJWLN3o=.12fc58aa-9316-4836-b523-ad3f14c84f4f@github.com> References: <1WRuP4yzJM1B_OmClef_sAtaL04ivqhwnW_CoJWLN3o=.12fc58aa-9316-4836-b523-ad3f14c84f4f@github.com> Message-ID: On Wed, 11 Aug 2021 00:04:24 GMT, Stuart Marks wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved SSH key section > > src/index.md line 1001: > >> 999: $ git remote add upstream git at github.com:openjdk/jdk.git >> 1000: >> 1001: In the example above I cloned my personal fork of the JDK mainline repository. You should of course use your own GitHub username instead. Then, by adding a new *remote* named 'upstream', we associate this clone with [openjdk/jdk](https://github.com/openjdk/jdk) as well. Doing this will allow the tooling to automatically create a PR request on [openjdk/jdk](https://github.com/openjdk/jdk) whenever you push a change to your personal fork. The way that works is that once you have pushed a change to your private fork, and navigate to the [openjdk/jdk](https://github.com/openjdk/jdk) repository on GitHub, there will be a message saying that you just pushed a change and asking if you want to create a PR. > > "PR request" => "PR" Fixed. > src/index.md line 1050: > >> 1048: * Click "Add SSH key" >> 1049: >> 1050: Now you are ready to clone your [openjdk/jdk](https://github.com/openjdk/jdk) fork using SSH. > > I suspect this SSH stuff is all fine for Linux and Mac. What about Windows? I imagine that one would need to install OpenSSH or something before this will work. I haven't done this though. I've never done this on Windows. I'll try to get hold of a windows machine to try it out and add a windows section later. > src/index.md line 1082: > >> 1080: $ curl https://download.java.net/java/GA/jdk16.0.1/7147401fd7354114ac51ef3e1328291f/9/GPL/openjdk-16.0.1_osx-x64_bin.tar.gz --output openjdk-16.0.1_osx-x64_bin.tar.gz >> 1081: $ tar xzf openjdk-16.0.1_osx-x64_bin.tar.gz >> 1082: $ # Get XCode from Appstore > > I think this should be a separate text paragraph, not a comment in what looks like a cookbook script to building the JDK. Getting XCode is kind of a problem. You can get it from the App Store; but sometimes the App Store version is too new for the OS version you have, so you have to get an older XCode. But of course if XCode is too old then it can't build the JDK. Obviously we can't write a whole section that covers all these issues. Plus, it changes from time to time as Apple releases new versions of things. I'd suggest having a separate paragraph that talks about getting XCode from the App Store, or the possible need to get older versions from Apple's developer site. I would avoid putting too many details in this document. Probably the best fallback is to tell people to ask on the mailing list if they have trouble with this step. I separated out the XCode info and put it in the text above, as a precondition to building. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 19:49:57 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 19:49:57 GMT Subject: RFR: Section on cloning [v4] In-Reply-To: References: Message-ID: > Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: git switch ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/59/files - new: https://git.openjdk.java.net/guide/pull/59/files/7afd9c76..e2b4205d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=03 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=02-03 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/guide/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/59/head:pull/59 PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 19:50:04 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 19:50:04 GMT Subject: RFR: Section on cloning [v2] In-Reply-To: <1WRuP4yzJM1B_OmClef_sAtaL04ivqhwnW_CoJWLN3o=.12fc58aa-9316-4836-b523-ad3f14c84f4f@github.com> References: <1WRuP4yzJM1B_OmClef_sAtaL04ivqhwnW_CoJWLN3o=.12fc58aa-9316-4836-b523-ad3f14c84f4f@github.com> Message-ID: On Wed, 11 Aug 2021 00:05:05 GMT, Stuart Marks wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved SSH key section > > src/index.md line 1006: > >> 1004: >> 1005: $ git checkout master >> 1006: $ git checkout -b my-fix > > I'm not sure whether we should recomment "git checkout -b" or "git switch -c". I think switch is safer, but the doc says that it's experimental.... Added a git switch example as well. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From kcr at openjdk.java.net Thu Aug 12 20:11:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 20:11:35 GMT Subject: RFR: Section on cloning [v3] In-Reply-To: <-AdCI1xrnXbHnD63Z7s_h7OnaS9Qbe6AHhmRVCK6xh0=.5b9a2d25-46db-46d9-826a-644ad22fc2b4@github.com> References: <-AdCI1xrnXbHnD63Z7s_h7OnaS9Qbe6AHhmRVCK6xh0=.5b9a2d25-46db-46d9-826a-644ad22fc2b4@github.com> Message-ID: On Thu, 12 Aug 2021 19:27:56 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Updates after review src/index.md line 999: > 997: > 998: $ git clone git at github.com:JesperIRL/jdk.git > 999: $ git remote add upstream git at github.com:openjdk/jdk.git I typically recommend using https for the "fetch" URL and "ssh" (i.e., `git@`) for the push URL. More importantly, I don't recommend using ssh at all for the upstream repo, since it is read-only for developers. Here is my suggestion: $ git clone https://github.com/JesperIRL/jdk.git $ cd jdk $ git remote set-url origin --push git at github.com:JesperIRL/jdk.git $ git remote add upstream https://github.com/openjdk/jdk.git If you prefer not to introduce the complexity of separate fetch and push URLs for `origin`, I at least would like to see an `https` URL for the upstream. src/index.md line 1006: > 1004: > 1005: $ git checkout master > 1006: $ git checkout -b JDK-8272373 Minor: you could achieve the same thing with: $ git checkout -b JDK-8272373 master ------------- PR: https://git.openjdk.java.net/guide/pull/59 From kcr at openjdk.java.net Thu Aug 12 20:11:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 20:11:36 GMT Subject: RFR: Section on cloning [v4] In-Reply-To: References: Message-ID: <-mLZzOBMP-hzedhIljXxE-97EV0yBBUrMZCNoBHGOO8=.1190a283-d656-47f4-8d66-43ad830aa888@github.com> On Thu, 12 Aug 2021 19:49:57 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > git switch src/index.md line 1021: > 1019: ## Generating an SSH key > 1020: > 1021: All pushes require an SSH key which must be installed on GitHub. If this is the first time you clone the [openjdk/jdk](https://github.com/openjdk/jdk) repository you may want to create an SSH key to use with it. For security reasons you should always create new keys and use different keys with each repository you clone. The `ssh-keygen` command generates an SSH key. The `-t` option determines which type of key to create. `ed25519` is recommended. `-C` is used to add a comment in the key file, to help you remember which key it is. While it?s possible to use SSH without a passphrase, this is **strongly discouraged**. Empty or insecure passphrases may be reset using `ssh-keygen -p`; this doesn?t change the keys. Maybe "if this is the first time you clone _your personal fork of_ the openjdk/jdk repo ..." ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 20:21:02 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 20:21:02 GMT Subject: RFR: Section about the release process [v4] In-Reply-To: References: Message-ID: > Answering some common questions around the release process. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: More on backing out a change ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/62/files - new: https://git.openjdk.java.net/guide/pull/62/files/32bf9285..5d54f57f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=62&range=03 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=62&range=02-03 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/guide/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/62/head:pull/62 PR: https://git.openjdk.java.net/guide/pull/62 From jwilhelm at openjdk.java.net Thu Aug 12 20:21:03 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 20:21:03 GMT Subject: RFR: Section about the release process [v2] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 00:41:51 GMT, Stuart Marks wrote: >> This is the way it works. I forward port all changes from JDK 17 to mainline, and if a change is not for mainline it must be backed out. I added a paragraph with your example to clarify the JBS part. > > OK. If this is the way it really works, then clearly that reality needs to be documented. I'm a bit surprised about this; on the other hand, I thought of several alternatives, but they're either unworkable or more complicated and don't offer any advantages. This is probably a pretty rare case, so maybe the workflow is fine as it stands. > > The filing-two-bugs material looks reasonable. I might strengthen it to say something like the following. > > ? As soon as you know that there is a fix that needs to go into the stabilization fork but not the mainline, you should do the following: file a bug JDK-yyy to cover the backout work, link it to JDK-xxx, set its Fix Version to the next release, add a comment describing the situation, and set the priority to be relatively high (e.g., P3). Then, you have to wait until the JDK-xxx fix is forward ported to the mainline before actually fixing JDK-yyy. Making these settings in JDK-yyy will help ensure that it won't be missed. ? I added your text, but as a list. ------------- PR: https://git.openjdk.java.net/guide/pull/62 From kcr at openjdk.java.net Thu Aug 12 20:30:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 20:30:34 GMT Subject: RFR: Roles in the OpenJDK [v5] In-Reply-To: <1NVlNrSjAs-8TQXPbCLIoS4SCJKiwIY4ub3zvkLH19k=.90f8452e-643e-4e99-8805-a502c99558b7@github.com> References: <1NVlNrSjAs-8TQXPbCLIoS4SCJKiwIY4ub3zvkLH19k=.90f8452e-643e-4e99-8805-a502c99558b7@github.com> Message-ID: On Thu, 12 Aug 2021 01:02:53 GMT, Jesper Wilhelmsson wrote: >> Added a short intro about OpenJDK describing Groups, Projects, and different roles. The sections on how to progress through the Author, Committer, Reviewer roles needs a broad agreement since that's an area that affects everyone and where there historically has been a lot of debate. This is a first draft, please comment. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Updated after review. Looks good. I left a couple minor comments. src/index.md line 38: > 36: ### Becoming an Author > 37: > 38: Becoming an [Author](https://openjdk.java.net/bylaws#author) is the first step. To achieve this you need to contribute two non-trivial changes to the project in which you wish to become an Author. Once your changes are pushed into the code base and has been vetted enough to determine that the changes were indeed good changes you can go ahead and send an email to the project lead of that particular project and ask to be added as an Author. > you need to contribute two non-trivial changes I don't see anything in the bylaws or JDK project docs that says the two sponsored changes have to be non-trivial to get an Author role (as opposed to Contributor or Reviewer). src/index.md line 107: > 105: ### 4. Create a tracking issue in JBS > 106: > 107: Many OpenJDK projects require a tracking issue to be filed in the [JDK Bug System (JBS)](https://bugs.openjdk.java.net/) before a change can be pushed. This is the case for instance for the JDK and the JDK-Updates projects. In order to get write access to JBS you need to be an [Author](https://openjdk.java.net/bylaws#author) in an OpenJDK project (see below). For your first changes, ask your sponsor to help you create the issue. Is it worth letting contributors know that they can file a bug at https://bugreport.java.com/ ? ------------- PR: https://git.openjdk.java.net/guide/pull/60 From kcr at openjdk.java.net Thu Aug 12 20:34:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 20:34:38 GMT Subject: RFR: Section about the release process [v4] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 20:21:02 GMT, Jesper Wilhelmsson wrote: >> Answering some common questions around the release process. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > More on backing out a change Marked as reviewed by kcr (no project role). ------------- PR: https://git.openjdk.java.net/guide/pull/62 From jwilhelm at openjdk.java.net Thu Aug 12 23:06:37 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 23:06:37 GMT Subject: RFR: Section on cloning [v3] In-Reply-To: References: <-AdCI1xrnXbHnD63Z7s_h7OnaS9Qbe6AHhmRVCK6xh0=.5b9a2d25-46db-46d9-826a-644ad22fc2b4@github.com> Message-ID: On Thu, 12 Aug 2021 20:01:37 GMT, Kevin Rushforth wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates after review > > src/index.md line 999: > >> 997: >> 998: $ git clone git at github.com:JesperIRL/jdk.git >> 999: $ git remote add upstream git at github.com:openjdk/jdk.git > > I typically recommend using https for the "fetch" URL and "ssh" (i.e., `git@`) for the push URL. More importantly, I don't recommend using ssh at all for the upstream repo, since it is read-only for developers. Here is my suggestion: > > > $ git clone https://github.com/JesperIRL/jdk.git > $ cd jdk > $ git remote set-url origin --push git at github.com:JesperIRL/jdk.git > $ git remote add upstream https://github.com/openjdk/jdk.git > > > If you prefer not to introduce the complexity of separate fetch and push URLs for `origin`, I at least would like to see an `https` URL for the upstream. How do we motivate recommending https for upstream? I mean it's not as if people can push regardless. Is there a git convention to use https for read only repos? ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 23:15:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 23:15:59 GMT Subject: RFR: Section on cloning [v5] In-Reply-To: References: Message-ID: > Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Updates after review ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/59/files - new: https://git.openjdk.java.net/guide/pull/59/files/e2b4205d..a38a016a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=04 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/guide/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/59/head:pull/59 PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 23:16:04 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 23:16:04 GMT Subject: RFR: Section on cloning [v3] In-Reply-To: References: <-AdCI1xrnXbHnD63Z7s_h7OnaS9Qbe6AHhmRVCK6xh0=.5b9a2d25-46db-46d9-826a-644ad22fc2b4@github.com> Message-ID: On Thu, 12 Aug 2021 20:03:50 GMT, Kevin Rushforth wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates after review > > src/index.md line 1006: > >> 1004: >> 1005: $ git checkout master >> 1006: $ git checkout -b JDK-8272373 > > Minor: you could achieve the same thing with: > > > $ git checkout -b JDK-8272373 master Nice! Fixed. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 23:16:08 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 23:16:08 GMT Subject: RFR: Section on cloning [v4] In-Reply-To: <-mLZzOBMP-hzedhIljXxE-97EV0yBBUrMZCNoBHGOO8=.1190a283-d656-47f4-8d66-43ad830aa888@github.com> References: <-mLZzOBMP-hzedhIljXxE-97EV0yBBUrMZCNoBHGOO8=.1190a283-d656-47f4-8d66-43ad830aa888@github.com> Message-ID: On Thu, 12 Aug 2021 20:07:08 GMT, Kevin Rushforth wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> git switch > > src/index.md line 1021: > >> 1019: ## Generating an SSH key >> 1020: >> 1021: All pushes require an SSH key which must be installed on GitHub. If this is the first time you clone the [openjdk/jdk](https://github.com/openjdk/jdk) repository you may want to create an SSH key to use with it. For security reasons you should always create new keys and use different keys with each repository you clone. The `ssh-keygen` command generates an SSH key. The `-t` option determines which type of key to create. `ed25519` is recommended. `-C` is used to add a comment in the key file, to help you remember which key it is. While it?s possible to use SSH without a passphrase, this is **strongly discouraged**. Empty or insecure passphrases may be reset using `ssh-keygen -p`; this doesn?t change the keys. > > Maybe "if this is the first time you clone _your personal fork of_ the openjdk/jdk repo ..." Fixed. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 23:33:00 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 23:33:00 GMT Subject: RFR: Section on cloning [v6] In-Reply-To: References: Message-ID: > Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: More updates after review ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/59/files - new: https://git.openjdk.java.net/guide/pull/59/files/a38a016a..95e7242f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=05 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/guide/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/59/head:pull/59 PR: https://git.openjdk.java.net/guide/pull/59 From kcr at openjdk.java.net Thu Aug 12 23:38:32 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 23:38:32 GMT Subject: RFR: Section on cloning [v3] In-Reply-To: References: <-AdCI1xrnXbHnD63Z7s_h7OnaS9Qbe6AHhmRVCK6xh0=.5b9a2d25-46db-46d9-826a-644ad22fc2b4@github.com> Message-ID: On Thu, 12 Aug 2021 23:03:39 GMT, Jesper Wilhelmsson wrote: >> src/index.md line 999: >> >>> 997: >>> 998: $ git clone git at github.com:JesperIRL/jdk.git >>> 999: $ git remote add upstream git at github.com:openjdk/jdk.git >> >> I typically recommend using https for the "fetch" URL and "ssh" (i.e., `git@`) for the push URL. More importantly, I don't recommend using ssh at all for the upstream repo, since it is read-only for developers. Here is my suggestion: >> >> >> $ git clone https://github.com/JesperIRL/jdk.git >> $ cd jdk >> $ git remote set-url origin --push git at github.com:JesperIRL/jdk.git >> $ git remote add upstream https://github.com/openjdk/jdk.git >> >> >> If you prefer not to introduce the complexity of separate fetch and push URLs for `origin`, I at least would like to see an `https` URL for the upstream. > > How do we motivate recommending https for upstream? I mean it's not as if people can push regardless. Is there a git convention to use https for read only repos? GitHub defaults to https when you click on the green "Code" button to get the URL of a repo to clone. The Skara tooling also uses https URLs for openjdk/jdk in its examples (e.g., the example of fetching a pull request locally for testing). It seems better to suggest anonymous https for remotes that you don't need to push to (such as the upstream openjdk/jdk). For the user's personal fork it really doesn't matter, so maybe it's better to drop that part of my suggestion (it's simpler too). So perhaps this? $ git clone git at github.com:JesperIRL/jdk.git $ cd jdk $ git remote add upstream https://github.com/openjdk/jdk.git ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Thu Aug 12 23:48:52 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 23:48:52 GMT Subject: RFR: Roles in the OpenJDK [v5] In-Reply-To: References: <1NVlNrSjAs-8TQXPbCLIoS4SCJKiwIY4ub3zvkLH19k=.90f8452e-643e-4e99-8805-a502c99558b7@github.com> Message-ID: On Thu, 12 Aug 2021 20:27:59 GMT, Kevin Rushforth wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated after review. > > Looks good. I left a couple minor comments. Thank you for your review @kevinrushforth > src/index.md line 38: > >> 36: ### Becoming an Author >> 37: >> 38: Becoming an [Author](https://openjdk.java.net/bylaws#author) is the first step. To achieve this you need to contribute two non-trivial changes to the project in which you wish to become an Author. Once your changes are pushed into the code base and has been vetted enough to determine that the changes were indeed good changes you can go ahead and send an email to the project lead of that particular project and ask to be added as an Author. > >> you need to contribute two non-trivial changes > > I don't see anything in the bylaws or JDK project docs that says the two sponsored changes have to be non-trivial to get an Author role (as opposed to Contributor or Reviewer). You're absolutely right. Removed "non-trivial". > src/index.md line 107: > >> 105: ### 4. Create a tracking issue in JBS >> 106: >> 107: Many OpenJDK projects require a tracking issue to be filed in the [JDK Bug System (JBS)](https://bugs.openjdk.java.net/) before a change can be pushed. This is the case for instance for the JDK and the JDK-Updates projects. In order to get write access to JBS you need to be an [Author](https://openjdk.java.net/bylaws#author) in an OpenJDK project (see below). For your first changes, ask your sponsor to help you create the issue. > > Is it worth letting contributors know that they can file a bug at https://bugreport.java.com/ ? Yes. Added. ------------- PR: https://git.openjdk.java.net/guide/pull/60 From jwilhelm at openjdk.java.net Thu Aug 12 23:48:51 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 12 Aug 2021 23:48:51 GMT Subject: RFR: Roles in the OpenJDK [v6] In-Reply-To: References: Message-ID: > Added a short intro about OpenJDK describing Groups, Projects, and different roles. The sections on how to progress through the Author, Committer, Reviewer roles needs a broad agreement since that's an area that affects everyone and where there historically has been a lot of debate. This is a first draft, please comment. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Updates after review ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/60/files - new: https://git.openjdk.java.net/guide/pull/60/files/a6de4771..414ccfc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=60&range=05 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=60&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/guide/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/60/head:pull/60 PR: https://git.openjdk.java.net/guide/pull/60 From jwilhelm at openjdk.java.net Fri Aug 13 00:04:52 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 13 Aug 2021 00:04:52 GMT Subject: RFR: Section on cloning [v7] In-Reply-To: References: Message-ID: > Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Changed to https for upstream ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/59/files - new: https://git.openjdk.java.net/guide/pull/59/files/95e7242f..37442137 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=06 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=05-06 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/guide/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/59/head:pull/59 PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Fri Aug 13 00:04:53 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 13 Aug 2021 00:04:53 GMT Subject: RFR: Section on cloning [v2] In-Reply-To: <1WRuP4yzJM1B_OmClef_sAtaL04ivqhwnW_CoJWLN3o=.12fc58aa-9316-4836-b523-ad3f14c84f4f@github.com> References: <1WRuP4yzJM1B_OmClef_sAtaL04ivqhwnW_CoJWLN3o=.12fc58aa-9316-4836-b523-ad3f14c84f4f@github.com> Message-ID: <_ZNBpwW4QLJYDnP2IhF3DkxVq333b0fg6xhLwcVUGaY=.0f6e3d81-8848-41c0-8142-ec5af1bc1b26@github.com> On Wed, 11 Aug 2021 00:10:59 GMT, Stuart Marks wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved SSH key section > > Marked as reviewed by smarks (Author). Thank you @stuart-marks and @kevinrushforth for your reviews ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Fri Aug 13 00:04:53 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 13 Aug 2021 00:04:53 GMT Subject: RFR: Section on cloning [v3] In-Reply-To: References: <-AdCI1xrnXbHnD63Z7s_h7OnaS9Qbe6AHhmRVCK6xh0=.5b9a2d25-46db-46d9-826a-644ad22fc2b4@github.com> Message-ID: On Thu, 12 Aug 2021 23:35:50 GMT, Kevin Rushforth wrote: >> How do we motivate recommending https for upstream? I mean it's not as if people can push regardless. Is there a git convention to use https for read only repos? > > GitHub defaults to https when you click on the green "Code" button to get the URL of a repo to clone. The Skara tooling also uses https URLs for openjdk/jdk in its examples (e.g., the example of fetching a pull request locally for testing). It seems better to suggest anonymous https for remotes that you don't need to push to (such as the upstream openjdk/jdk). > > For the user's personal fork it really doesn't matter, so maybe it's better to drop that part of my suggestion (it's simpler too). So perhaps this? > > > $ git clone git at github.com:JesperIRL/jdk.git > $ cd jdk > $ git remote add upstream https://github.com/openjdk/jdk.git Ok. Changed. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From dholmes at openjdk.java.net Fri Aug 13 02:21:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 13 Aug 2021 02:21:35 GMT Subject: RFR: Section on cloning [v7] In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 00:04:52 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Changed to https for upstream Hi Jesper, There seems to be quite a bit of overlap/duplication with what can be found on the skara wiki. I don't think it makes sense to duplicate technical details, especially when so much is subjective (http vs. https vs. ssh). I'd rather see links to that wiki and the wiki itself updated if needed. Cheers, David ------------- PR: https://git.openjdk.java.net/guide/pull/59 From kcr at openjdk.java.net Fri Aug 13 11:01:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Aug 2021 11:01:35 GMT Subject: RFR: Section on cloning [v7] In-Reply-To: References: Message-ID: <0PxYvC82qe5LF2ZEvb3Ph7_G4a874PR3aECgVdWmy5c=.d30fa574-3bc3-4849-8720-84411ccda88c@github.com> On Fri, 13 Aug 2021 00:04:52 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Changed to https for upstream Marked as reviewed by kcr (no project role). ------------- PR: https://git.openjdk.java.net/guide/pull/59 From kcr at openjdk.java.net Fri Aug 13 11:02:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Aug 2021 11:02:39 GMT Subject: RFR: Roles in the OpenJDK [v6] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 23:48:51 GMT, Jesper Wilhelmsson wrote: >> Added a short intro about OpenJDK describing Groups, Projects, and different roles. The sections on how to progress through the Author, Committer, Reviewer roles needs a broad agreement since that's an area that affects everyone and where there historically has been a lot of debate. This is a first draft, please comment. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Updates after review Marked as reviewed by kcr (no project role). ------------- PR: https://git.openjdk.java.net/guide/pull/60 From aph-open at littlepinkcloud.com Sat Aug 14 09:28:34 2021 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sat, 14 Aug 2021 10:28:34 +0100 Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas Message-ID: https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says: "Undecided Features This list is incomplete; it serves to explicitly call out some features that have not yet been discussed. ... Lambdas" I can't see any reason to forbid Lambdas from a performance point of view, and they can add to readability and maintainability in C++ for the same reasons that they do in Java. I have a job I'm working on (in the AArch64 back end) where Lambdas would be very useful. How about I give it a try, and I'll produce the patch for review, as an initial proposal? Then anyone can put in their 2c worth. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Sat Aug 14 18:25:40 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 14 Aug 2021 18:25:40 +0000 Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas In-Reply-To: References: Message-ID: > On Aug 14, 2021, at 5:28 AM, Andrew Haley wrote: > > https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says: > > "Undecided Features > > This list is incomplete; it serves to explicitly call out some > features that have not yet been discussed. ... Lambdas" > > I can't see any reason to forbid Lambdas from a performance point of > view, and they can add to readability and maintainability in C++ for > the same reasons that they do in Java. > > I have a job I'm working on (in the AArch64 back end) where Lambdas > would be very useful. How about I give it a try, and I'll produce the > patch for review, as an initial proposal? Then anyone can put in their > 2c worth. Funny you should mention lambdas. There has been a fair amount of discussion around them internally here at Oracle. And there are some folks trying them out in not-yet-ready-for-production work. I?ve drafted a style-guide modification reflecting that discussion, along with a couple examples, and am planning to open a PR in the next few days. You can see the current work in progress here: https://github.com/kimbarrett/openjdk-jdk/tree/permit_lambda Note that I'm planning to rebase and do some commit refactoring / reordering before opening the PR. There is one downside that has recently been noted. Stack frame names in stack traces where lambdas are involved are pretty indecipherable. From stefan.karlsson at oracle.com Mon Aug 16 06:19:43 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Aug 2021 08:19:43 +0200 Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas In-Reply-To: References: Message-ID: <78fa5233-c08a-384a-4689-0c7b6be97849@oracle.com> On 2021-08-14 20:25, Kim Barrett wrote: >> On Aug 14, 2021, at 5:28 AM, Andrew Haley wrote: >> >> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says: >> >> "Undecided Features >> >> This list is incomplete; it serves to explicitly call out some >> features that have not yet been discussed. ... Lambdas" >> >> I can't see any reason to forbid Lambdas from a performance point of >> view, and they can add to readability and maintainability in C++ for >> the same reasons that they do in Java. >> >> I have a job I'm working on (in the AArch64 back end) where Lambdas >> would be very useful. How about I give it a try, and I'll produce the >> patch for review, as an initial proposal? Then anyone can put in their >> 2c worth. > Funny you should mention lambdas. There has been a fair amount of > discussion around them internally here at Oracle. And there are some > folks trying them out in not-yet-ready-for-production work. We've been trying this out in the zgc_generational branch: https://github.com/openjdk/zgc/tree/zgc_generational For anyone that wants to take a look, search for [&]. > I?ve drafted > a style-guide modification reflecting that discussion, along with a couple > examples, and am planning to open a PR in the next few days. > > You can see the current work in progress here: > > https://github.com/kimbarrett/openjdk-jdk/tree/permit_lambda > > Note that I'm planning to rebase and do some commit refactoring / reordering > before opening the PR. > > There is one downside that has recently been noted. Stack frame names > in stack traces where lambdas are involved are pretty indecipherable. Just to give an example what the frames sometimes look like in the debugger: #3 ZPageTableParallelIterator::do_pages(ZRememberScanPageTask::work()::{lambda(ZPage*)#1})::{lambda(ZPage*)#1}>(ZGenerationPagesParallelIterator::do_pages(ZRememberScanPageTask::work()::{lambda(ZPage*)#1})::{lambda(ZPage*)#1})::{lambda(int)#1}::operator()(int) const (index=, this=) at /home/stefank/git/alt/open/src/hotspot/share/gc/z/zPageTable.inline.hpp:75 It's not this bad all the time, but it seems easy to end up in this situation when you write generic iterator code that accepts lambdas. StefanK > From kim.barrett at oracle.com Tue Aug 17 14:00:51 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Aug 2021 14:00:51 +0000 Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas In-Reply-To: References: Message-ID: <7CA77D40-F95D-43C2-9748-E62C4F8D12D2@oracle.com> > On Aug 14, 2021, at 2:25 PM, Kim Barrett wrote: > >> On Aug 14, 2021, at 5:28 AM, Andrew Haley wrote: >> >> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says: >> >> "Undecided Features >> >> This list is incomplete; it serves to explicitly call out some >> features that have not yet been discussed. ... Lambdas" >> > > Funny you should mention lambdas. There has been a fair amount of > discussion around them internally here at Oracle. And there are some > folks trying them out in not-yet-ready-for-production work. I?ve drafted > a style-guide modification reflecting that discussion, along with a couple > examples, and am planning to open a PR in the next few days. > > You can see the current work in progress here: > > https://github.com/kimbarrett/openjdk-jdk/tree/permit_lambda > > Note that I'm planning to rebase and do some commit refactoring / reordering > before opening the PR. https://github.com/openjdk/jdk/pull/5144 From jesper.wilhelmsson at oracle.com Tue Aug 17 20:18:08 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 Aug 2021 20:18:08 +0000 Subject: CFV: New JDK Committer: Stuart Marks Message-ID: <5906DD88-2F62-48D6-877B-B957EEF422DF@oracle.com> I hereby nominate Stuart Marks (smarks)[1] to Developers' Guide Committer. Stuart is a member of the Oracle JDK Core Libraries team and has through the years proven his solid knowledge in OpenJDK development processes in many different ways. Over the last year he has been active in the Developers' Guide Project and has contributed with wisdom through thorough reviews and by authoring sections to the Guide. Votes are due by 2021-08-31 23:59 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. /Jesper [1] https://openjdk.java.net/census#smarks [2] https://openjdk.java.net/census#jdk [3] https://openjdk.java.net/projects/#committer-vote From jesper.wilhelmsson at oracle.com Tue Aug 17 20:24:08 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 Aug 2021 20:24:08 +0000 Subject: CFV: New JDK Committer: Stuart Marks In-Reply-To: <5906DD88-2F62-48D6-877B-B957EEF422DF@oracle.com> References: <5906DD88-2F62-48D6-877B-B957EEF422DF@oracle.com> Message-ID: <912DCA21-3519-476E-A485-6E201DF7F38B@oracle.com> Correction: Only current Developers' Guide Committers are eligible to vote on this nomination. /Jesper > 17 aug. 2021 kl. 22:18 skrev Jesper Wilhelmsson : > > I hereby nominate Stuart Marks (smarks)[1] to Developers' Guide Committer. > > Stuart is a member of the Oracle JDK Core Libraries team and has through the years proven his solid knowledge in OpenJDK development processes in many different ways. Over the last year he has been active in the Developers' Guide Project and has contributed with wisdom through thorough reviews and by authoring sections to the Guide. > > Votes are due by 2021-08-31 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > /Jesper > > [1] https://openjdk.java.net/census#smarks > [2] https://openjdk.java.net/census#guide > [3] https://openjdk.java.net/projects/#committer-vote > From jesper.wilhelmsson at oracle.com Tue Aug 17 21:02:39 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 Aug 2021 21:02:39 +0000 Subject: CFV: New Developers' Guide Committer: Stuart Marks Message-ID: Take two. Now with the correct subject. I hereby nominate Stuart Marks (smarks)[1] to Developers' Guide Committer. Stuart is a member of the Oracle JDK Core Libraries team and has through the years proven his solid knowledge in OpenJDK development processes in many different ways. Over the last year he has been active in the Developers' Guide Project and has contributed with wisdom through thorough reviews and by authoring sections to the Guide. Votes are due by 2021-08-31 23:59 UTC. Only current Developers' Guide Committers [2] are eligible to vote on this nomination. (Yes, there are only three of us at the moment.) Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. /Jesper [1] https://openjdk.java.net/census#smarks [2] https://openjdk.java.net/census#guide [3] https://openjdk.java.net/projects/#committer-vote From jesper.wilhelmsson at oracle.com Tue Aug 17 21:04:35 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 Aug 2021 21:04:35 +0000 Subject: CFV: New Developers' Guide Committer: Stuart Marks In-Reply-To: References: Message-ID: <1C9F4866-FA63-427F-982B-1510F9A763CA@oracle.com> Vote: Yes Is the nomination counted as an implicit yes vote? /Jesper > 17 aug. 2021 kl. 23:02 skrev Jesper Wilhelmsson : > > Take two. Now with the correct subject. > > I hereby nominate Stuart Marks (smarks)[1] to Developers' Guide Committer. > > Stuart is a member of the Oracle JDK Core Libraries team and has through the years proven his solid knowledge in OpenJDK development processes in many different ways. Over the last year he has been active in the Developers' Guide Project and has contributed with wisdom through thorough reviews and by authoring sections to the Guide. > > Votes are due by 2021-08-31 23:59 UTC. > > Only current Developers' Guide Committers [2] are eligible to vote on this nomination. (Yes, there are only three of us at the moment.) > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > /Jesper > > [1] https://openjdk.java.net/census#smarks > [2] https://openjdk.java.net/census#guide > [3] https://openjdk.java.net/projects/#committer-vote > From jwilhelm at openjdk.java.net Fri Aug 20 00:26:55 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 20 Aug 2021 00:26:55 GMT Subject: RFR: Section on cloning [v8] In-Reply-To: References: Message-ID: > Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Introduced SSH earlier ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/59/files - new: https://git.openjdk.java.net/guide/pull/59/files/37442137..d43feb07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=07 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=06-07 Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/guide/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/59/head:pull/59 PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Fri Aug 20 00:30:38 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 20 Aug 2021 00:30:38 GMT Subject: RFR: Section on cloning [v8] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 00:26:55 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Introduced SSH earlier I tried with a newly created GitHub account and verified that the SSH key is required already when cloning. So I added an initial clone example that uses https. Also added references to the Skara documentation. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From dholmes at openjdk.java.net Sun Aug 22 22:34:32 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 22 Aug 2021 22:34:32 GMT Subject: RFR: Section on cloning [v8] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 00:26:55 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Introduced SSH earlier Hi Jesper, A couple of minor nits but otherwise seems a reasonable balance of information to get someone started. Thanks, David src/index.md line 1001: > 999: $ git clone https://github.com/openjdk/jdk.git > 1000: > 1001: If you intend to contribute patches to the JDK, you should first *fork* the JDK repository on GitHub and clone your own fork as shown below. To fork a project on GitHub, go to the [project page](https://github.com/openjdk/jdk) and click the 'Fork' button in the upper right corner, then follow the on screen instructions. s/own fork/own personal fork/ This introduces the "personal fork" terminology. src/index.md line 1003: > 1001: If you intend to contribute patches to the JDK, you should first *fork* the JDK repository on GitHub and clone your own fork as shown below. To fork a project on GitHub, go to the [project page](https://github.com/openjdk/jdk) and click the 'Fork' button in the upper right corner, then follow the on screen instructions. > 1002: > 1003: All pushes to [openjdk/jdk](https://github.com/openjdk/jdk) require an SSH key which must be installed on GitHub. If this is the first time you clone your personal fork of the [openjdk/jdk](https://github.com/openjdk/jdk) repository you may want to create an SSH key to use with it. See [Generating an SSH key] below. Once you have your private fork and an SSH key to go with it, go ahead and clone. s/private fork/personal fork/ src/index.md line 1009: > 1007: $ git remote add upstream https://github.com/openjdk/jdk.git > 1008: > 1009: In the example above Duke cloned his personal fork of the JDK mainline repository using SSH. You should of course use your own GitHub username instead. Then, by adding a new *remote* named 'upstream', the clone is associated with [openjdk/jdk](https://github.com/openjdk/jdk). Doing this will allow the tooling to automatically create a PR on [openjdk/jdk](https://github.com/openjdk/jdk) whenever a change is pushed to the personal fork. The way that works is that once the change has been pushed to the private fork, and you navigate to the [openjdk/jdk](https://github.com/openjdk/jdk) repository on GitHub, there will be a message saying that you just pushed a change and asking if you want to create a PR. s/private fork/personal fork/ ------------- Marked as reviewed by dholmes (Author). PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Sun Aug 22 23:34:02 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sun, 22 Aug 2021 23:34:02 GMT Subject: RFR: Section on cloning [v9] In-Reply-To: References: Message-ID: > Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Personal clone ------------- Changes: - all: https://git.openjdk.java.net/guide/pull/59/files - new: https://git.openjdk.java.net/guide/pull/59/files/d43feb07..fc4994cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=08 - incr: https://webrevs.openjdk.java.net/?repo=guide&pr=59&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/guide/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/guide pull/59/head:pull/59 PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Sun Aug 22 23:34:05 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sun, 22 Aug 2021 23:34:05 GMT Subject: RFR: Section on cloning [v7] In-Reply-To: References: Message-ID: <0Of7qe5XvI_qn3k5HfD0WuObm6TL5QaXhZUP-Ran0OE=.00096047-0c5a-4a14-8062-ad5b2069e020@github.com> On Fri, 13 Aug 2021 02:18:34 GMT, David Holmes wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed to https for upstream > > Hi Jesper, > > There seems to be quite a bit of overlap/duplication with what can be found on the skara wiki. I don't think it makes sense to duplicate technical details, especially when so much is subjective (http vs. https vs. ssh). I'd rather see links to that wiki and the wiki itself updated if needed. > > Cheers, > David Thank you for your review @dholmes-ora! ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Sun Aug 22 23:34:10 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sun, 22 Aug 2021 23:34:10 GMT Subject: RFR: Section on cloning [v8] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 22:19:43 GMT, David Holmes wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduced SSH earlier > > src/index.md line 1001: > >> 999: $ git clone https://github.com/openjdk/jdk.git >> 1000: >> 1001: If you intend to contribute patches to the JDK, you should first *fork* the JDK repository on GitHub and clone your own fork as shown below. To fork a project on GitHub, go to the [project page](https://github.com/openjdk/jdk) and click the 'Fork' button in the upper right corner, then follow the on screen instructions. > > s/own fork/own personal fork/ > > This introduces the "personal fork" terminology. Fixed. > src/index.md line 1003: > >> 1001: If you intend to contribute patches to the JDK, you should first *fork* the JDK repository on GitHub and clone your own fork as shown below. To fork a project on GitHub, go to the [project page](https://github.com/openjdk/jdk) and click the 'Fork' button in the upper right corner, then follow the on screen instructions. >> 1002: >> 1003: All pushes to [openjdk/jdk](https://github.com/openjdk/jdk) require an SSH key which must be installed on GitHub. If this is the first time you clone your personal fork of the [openjdk/jdk](https://github.com/openjdk/jdk) repository you may want to create an SSH key to use with it. See [Generating an SSH key] below. Once you have your private fork and an SSH key to go with it, go ahead and clone. > > s/private fork/personal fork/ Fixed. > src/index.md line 1009: > >> 1007: $ git remote add upstream https://github.com/openjdk/jdk.git >> 1008: >> 1009: In the example above Duke cloned his personal fork of the JDK mainline repository using SSH. You should of course use your own GitHub username instead. Then, by adding a new *remote* named 'upstream', the clone is associated with [openjdk/jdk](https://github.com/openjdk/jdk). Doing this will allow the tooling to automatically create a PR on [openjdk/jdk](https://github.com/openjdk/jdk) whenever a change is pushed to the personal fork. The way that works is that once the change has been pushed to the private fork, and you navigate to the [openjdk/jdk](https://github.com/openjdk/jdk) repository on GitHub, there will be a message saying that you just pushed a change and asking if you want to create a PR. > > s/private fork/personal fork/ Fixed. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From iris at openjdk.java.net Tue Aug 24 17:36:35 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 24 Aug 2021 17:36:35 GMT Subject: RFR: Section on cloning [v9] In-Reply-To: References: Message-ID: <89gi9c2Pxy7JW56USRAReTuQ_SlYX5OOJtiUHqBxsFc=.0ba52d19-236b-4881-a300-d9339942ea20@github.com> On Sun, 22 Aug 2021 23:34:02 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Personal clone src/index.md line 1466: > 1464: +-----------------+ > 1465: > 1466: The `~/.ssh/id_rsa.pub` is a text file containing the public ssh key. This file should be mailed as an attachment along with the JDK username to [keys(at)openjdk.java.net](mailto:keys-at-openjdk.java.net). An administrator will install your key on the server and notify you on completion. This process may take a couple of days. I'm not sure how to handle this. All of the new section is about using Git; however, these instructions for sending to keys at ojn are still needed for the very few Projects which still develop using hg.ojn or for those intending to use cr.ojn. I referenced them in the past few weeks when helping a user so I'm reluctant to completely eliminate these few sentences quite yet. ------------- PR: https://git.openjdk.java.net/guide/pull/59 From iris at openjdk.java.net Tue Aug 24 17:47:39 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 24 Aug 2021 17:47:39 GMT Subject: RFR: Section about the release process [v4] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 20:21:02 GMT, Jesper Wilhelmsson wrote: >> Answering some common questions around the release process. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > More on backing out a change Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/guide/pull/62 From iris at openjdk.java.net Tue Aug 24 23:49:36 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 24 Aug 2021 23:49:36 GMT Subject: RFR: Roles in the OpenJDK [v6] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 23:48:51 GMT, Jesper Wilhelmsson wrote: >> Added a short intro about OpenJDK describing Groups, Projects, and different roles. The sections on how to progress through the Author, Committer, Reviewer roles needs a broad agreement since that's an area that affects everyone and where there historically has been a lot of debate. This is a first draft, please comment. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Updates after review Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/guide/pull/60 From ihse at openjdk.java.net Wed Aug 25 08:43:38 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 25 Aug 2021 08:43:38 GMT Subject: RFR: Section on cloning [v9] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:34:02 GMT, Jesper Wilhelmsson wrote: >> Added a section on cloning from GitHub, and an example of building on Mac. Also fixed two minor bugs that caused problems with syntax highlighting in Atom. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Personal clone Changes requested by ihse (Author). src/index.md line 1003: > 1001: If you intend to contribute patches to the JDK, you should first *fork* the JDK repository on GitHub and clone your own *personal fork* as shown below. To fork a project on GitHub, go to the [project page](https://github.com/openjdk/jdk) and click the 'Fork' button in the upper right corner, then follow the on screen instructions. > 1002: > 1003: All pushes to [openjdk/jdk](https://github.com/openjdk/jdk) require an SSH key which must be installed on GitHub. If this is the first time you clone your personal fork of the [openjdk/jdk](https://github.com/openjdk/jdk) repository you may want to create an SSH key to use with it. See [Generating an SSH key] below. Once you have your personal fork and an SSH key to go with it, go ahead and clone. This comment is either wrong or irrelevant. A normal developer cannot push to the openjdk/jdk repo. For your personal fork, you may chose to not use SSH, and instead use https. src/index.md line 1017: > 1015: Here we create a new branch called `JDK-8272373` based on the `master` branch and set the repository up to work in that new branch. > 1016: > 1017: Starting from Git version 2.23 there's also `git switch` that can be used instead of `git checkout`. Since 'git checkout' has the potential for catastrophic data loss, all modern git usage suggest using 'git switch' for switching branches. I recommend you suggest just 'git switch' and then perhaps parenthetically notices that prior to git 2.23 'git checkout' is needed instead. src/index.md line 1027: > 1025: ## Generating an SSH key > 1026: > 1027: For security reasons you should always create new keys and use different keys with each repository you clone. The `ssh-keygen` command generates an SSH key. The `-t` option determines which type of key to create. `ed25519` is recommended. `-C` is used to add a comment in the key file, to help you remember which key it is. While it?s possible to use SSH without a passphrase, this is **strongly discouraged**. Empty or insecure passphrases may be reset using `ssh-keygen -p`; this doesn?t change the keys. Personally, I believe using ssh is a lot of hassle (as these paragraphs shows; a third of the new section is devoted to ssh key handling) and think the https/PAT route is much simpler. Maybe you should at least mention it as an alternative, if you do not want to suggest it as the primary way to access Github. src/index.md line 1090: > 1088: > 1089: The second example is from a clean (newly installed) Mac running MacOS Big Sur. Please note that in this case there are some steps taken outside of the terminal. First XCode and the XCode command line tools must be installed. It could be that the most recent version of XCode that you get from App Store is too new to have been properly tested with the JDK build. See [the JDK build instructions](https://github.com/openjdk/jdk/blob/master/doc/building.md#apple-xcode) for supported versions and more details in case you need to install an older version of XCode. > 1090: In this example [Mac Ports](https://www.macports.org) is used to install `autoconf`. `autoconf` can also be installed using [Homebrew](https://brew.sh) and surely through other sources as well. Mac Ports is virtually dead. Homebrew usage dwarfs Mac Ports by magnitudes (see https://www.scivision.dev/homebrew-macports-fink/ for usage data). I recommend you switch the example to use Homebrew (and possibly mentions Mac Ports, but seriously, I don't think anyone ever tried to build OpenJDK on mac using Mac Ports so I'm not sure how well that woks). ------------- PR: https://git.openjdk.java.net/guide/pull/59 From ihse at openjdk.java.net Wed Aug 25 08:43:39 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 25 Aug 2021 08:43:39 GMT Subject: RFR: Section on cloning [v9] In-Reply-To: <89gi9c2Pxy7JW56USRAReTuQ_SlYX5OOJtiUHqBxsFc=.0ba52d19-236b-4881-a300-d9339942ea20@github.com> References: <89gi9c2Pxy7JW56USRAReTuQ_SlYX5OOJtiUHqBxsFc=.0ba52d19-236b-4881-a300-d9339942ea20@github.com> Message-ID: <7r-rKM27jpe7ZSp2gRh5-NNUh2gzfvGzc_Hq1gx415Q=.2aeefda5-0b4f-42f5-b818-d079847a7b4f@github.com> On Tue, 24 Aug 2021 17:33:23 GMT, Iris Clark wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Personal clone > > src/index.md line 1466: > >> 1464: +-----------------+ >> 1465: >> 1466: The `~/.ssh/id_rsa.pub` is a text file containing the public ssh key. This file should be mailed as an attachment along with the JDK username to [keys(at)openjdk.java.net](mailto:keys-at-openjdk.java.net). An administrator will install your key on the server and notify you on completion. This process may take a couple of days. > > I'm not sure how to handle this. All of the new section is about using Git; however, these instructions for sending to keys at ojn are still needed for the very few Projects which still develop using hg.ojn or for those intending to use cr.ojn. I referenced them in the past few weeks when helping a user so I'm reluctant to completely eliminate these few sentences quite yet. Can we keep a section "How to do development on the legacy Mercurial server"? ------------- PR: https://git.openjdk.java.net/guide/pull/59 From jwilhelm at openjdk.java.net Fri Aug 27 07:59:33 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 27 Aug 2021 07:59:33 GMT Subject: Integrated: Roles in the OpenJDK In-Reply-To: References: Message-ID: <7NWBrvhn5aWAKeHFzzbbCSlUzxOtezDCPuFCueHk0Wo=.9be404b9-7f29-4991-a53a-bf4d2f6ca1c1@github.com> On Thu, 17 Jun 2021 23:39:41 GMT, Jesper Wilhelmsson wrote: > Added a short intro about OpenJDK describing Groups, Projects, and different roles. The sections on how to progress through the Author, Committer, Reviewer roles needs a broad agreement since that's an area that affects everyone and where there historically has been a lot of debate. This is a first draft, please comment. This pull request has now been integrated. Changeset: cbb1e697 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/guide/commit/cbb1e697b0188e992b8ca73e302a1b87a03189ea Stats: 74 lines in 1 file changed: 64 ins; 2 del; 8 mod Roles in the OpenJDK Reviewed-by: smarks, kcr, iris ------------- PR: https://git.openjdk.java.net/guide/pull/60 From jwilhelm at openjdk.java.net Fri Aug 27 08:04:38 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 27 Aug 2021 08:04:38 GMT Subject: Integrated: Section about the release process In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 23:06:14 GMT, Jesper Wilhelmsson wrote: > Answering some common questions around the release process. This pull request has now been integrated. Changeset: 6b3fe5d4 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/guide/commit/6b3fe5d470e53c7561b082fd5f2f5a4a9753fe55 Stats: 74 lines in 2 files changed: 70 ins; 3 del; 1 mod Section about the release process Reviewed-by: smarks, kcr, iris ------------- PR: https://git.openjdk.java.net/guide/pull/62