From jwilhelm at openjdk.org Mon May 5 19:10:11 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 5 May 2025 19:10:11 GMT Subject: RFR: Get agreement before PR Message-ID: Added a note on getting proper agreement on a change before creating a PR for it. ------------- Commit messages: - Get agreement before PR Changes: https://git.openjdk.org/guide/pull/150/files Webrev: https://webrevs.openjdk.org/?repo=guide&pr=150&range=00 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/guide/pull/150.diff Fetch: git fetch https://git.openjdk.org/guide.git pull/150/head:pull/150 PR: https://git.openjdk.org/guide/pull/150 From iris at openjdk.org Mon May 5 21:26:58 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 5 May 2025 21:26:58 GMT Subject: RFR: Get agreement before PR In-Reply-To: References: Message-ID: On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson wrote: > Added a note on getting proper agreement on a change before creating a PR for it. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/guide/pull/150#pullrequestreview-2816145545 From jwilhelm at openjdk.org Tue May 6 08:16:31 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 6 May 2025 08:16:31 GMT Subject: RFR: Get agreement before PR In-Reply-To: References: Message-ID: On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson wrote: > Added a note on getting proper agreement on a change before creating a PR for it. Thank you Iris! ------------- PR Comment: https://git.openjdk.org/guide/pull/150#issuecomment-2853654722 From jwilhelm at openjdk.org Tue May 6 08:16:31 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 6 May 2025 08:16:31 GMT Subject: Integrated: Get agreement before PR In-Reply-To: References: Message-ID: On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson wrote: > Added a note on getting proper agreement on a change before creating a PR for it. This pull request has now been integrated. Changeset: 47aa1027 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/guide/commit/47aa1027db2fae8cd84079447bee7c6dc6da3560 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Get agreement before PR Reviewed-by: iris ------------- PR: https://git.openjdk.org/guide/pull/150 From duke at openjdk.org Tue May 6 20:18:32 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 20:18:32 GMT Subject: RFR: Get agreement before PR In-Reply-To: References: Message-ID: <4-cffFDlrnLyAvwl0Op1JoMnIY5VQJbR4BsWq-yjGWQ=.53c0ddba-4259-40df-b603-7ca113258739@github.com> On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson wrote: > Added a note on getting proper agreement on a change before creating a PR for it. src/guide/contributing-to-an-open-jdk-project.md line 61: > 59: Once the OCA is signed, please restrain your urge to create a PR just a little while longer. In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists]. Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code. To understand the criteria by which your patch is going to be judged, please read [Why is My Change Rejected?] below. In short, hidden constraints and assumptions, stability and quality, maintainability, compatibility, and conformance to specifications must be considered before your PR is ready to be submitted. If you don't understand the constraints for acceptance, you might be surprised when your PR is rejected. > 60: > 61: Please note that lack of engagement should not be interpreted as supporting the proposal. Lack of engagement might be better interpreted as people are busy or maybe that the problem isn't compelling or high priority enough to spend time on right now. If you didn't get the desired attention and the required agreement in your mail thread, **do not** proceed to create a PR. By all due respect, but that wording effectively would have prevented *lots* of actually merged and appreciated PRs in the past -- even and in particular those from the core team members themselves, who often are *just few* people, acting on Gentleman's Agreement but not by "broad" agreement. In particular for smaller, well-understood fixes, there typically is no "broad" agreement, but "silent agreement", as everybody is fine with a fix. Hence, we should not stop ourselves *unless needed*. A discussion is fine *and needed* **for API changes**. A discussion *before showing code* for small fixes makes no sense at all and makes things overly complex, as how would you discuss whether it is fine to fix a code line without showing that codeline? ------------- PR Review Comment: https://git.openjdk.org/guide/pull/150#discussion_r2076213557 From alanb at openjdk.org Wed May 7 09:24:35 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 09:24:35 GMT Subject: RFR: Get agreement before PR In-Reply-To: <4-cffFDlrnLyAvwl0Op1JoMnIY5VQJbR4BsWq-yjGWQ=.53c0ddba-4259-40df-b603-7ca113258739@github.com> References: <4-cffFDlrnLyAvwl0Op1JoMnIY5VQJbR4BsWq-yjGWQ=.53c0ddba-4259-40df-b603-7ca113258739@github.com> Message-ID: On Tue, 6 May 2025 20:16:10 GMT, Markus KARG wrote: >> Added a note on getting proper agreement on a change before creating a PR for it. > > src/guide/contributing-to-an-open-jdk-project.md line 61: > >> 59: Once the OCA is signed, please restrain your urge to create a PR just a little while longer. In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists]. Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code. To understand the criteria by which your patch is going to be judged, please read [Why is My Change Rejected?] below. In short, hidden constraints and assumptions, stability and quality, maintainability, compatibility, and conformance to specifications must be considered before your PR is ready to be submitted. If you don't understand the constraints for acceptance, you might be surprised when your PR is rejected. >> 60: >> 61: Please note that lack of engagement should not be interpreted as supporting the proposal. Lack of engagement might be better interpreted as people are busy or maybe that the problem isn't compelling or high priority enough to spend time on right now. If you didn't get the desired attention and the required agreement in your mail thread, **do not** proceed to create a PR. > > By all due respect, but that wording effectively would have prevented *lots* of actually merged and appreciated PRs in the past -- even and in particular those from the core team members themselves, who often are *just few* people, acting on Gentleman's Agreement but not by "broad" agreement. In particular for smaller, well-understood fixes, there typically is no "broad" agreement, but "silent agreement", as everybody is fine with a fix. Hence, we should not stop ourselves *unless needed*. A discussion is fine *and needed* **for API changes**. A discussion *before showing code* for small fixes makes no sense at all and makes things overly complex, as how would you discuss whether it is fine to fix a code line without showing that codeline? I think you may be over reading this. When someone sends mail with a proposal for some feature or API then there is no obligation for anyone to respond. Lack of a timely response should not be interpreted as agreement with the proposal. The phrase "The absence of dissent is not the presence of consent" comes to mind. It may be annoying to not get a timely response from maintainers in specific areas but this shouldn't mean it's time to create a PR and start reviewing code and changes. Code first and "code is king" may be how many projects work but here, and especially for APIs, the code will often have negative value because it distracts from the bigger questions. One thing that has kinda worked on a few occasions is where a PR is created with an API and no implementation code, the intention being to focus on the API and avoid the distraction of folks trying to micro optimize before it's clear whether the proposal will get traction. ------------- PR Review Comment: https://git.openjdk.org/guide/pull/150#discussion_r2077207844 From ihse at openjdk.org Wed May 7 11:17:29 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 11:17:29 GMT Subject: RFR: Get agreement before PR In-Reply-To: References: <4-cffFDlrnLyAvwl0Op1JoMnIY5VQJbR4BsWq-yjGWQ=.53c0ddba-4259-40df-b603-7ca113258739@github.com> Message-ID: <4OkBAwzccGghMfRzXwUJh53a18wzSL2IzNZayeKgwss=.87b55c46-38ec-4ae1-90aa-93e7d65a13ec@github.com> On Wed, 7 May 2025 09:21:55 GMT, Alan Bateman wrote: >> src/guide/contributing-to-an-open-jdk-project.md line 61: >> >>> 59: Once the OCA is signed, please restrain your urge to create a PR just a little while longer. In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists]. Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code. To understand the criteria by which your patch is going to be judged, please read [Why is My Change Rejected?] below. In short, hidden constraints and assumptions, stability and quality, maintainability, compatibility, and conformance to specifications must be considered before your PR is ready to be submitted. If you don't understand the constraints for acceptance, you might be surprised when your PR is rejected. >>> 60: >>> 61: Please note that lack of engagement should not be interpreted as supporting the proposal. Lack of engagement might be better interpreted as people are busy or maybe that the problem isn't compelling or high priority enough to spend time on right now. If you didn't get the desired attention and the required agreement in your mail thread, **do not** proceed to create a PR. >> >> By all due respect, but that wording effectively would have prevented *lots* of actually merged and appreciated PRs in the past -- even and in particular those from the core team members themselves, who often are *just few* people, acting on Gentleman's Agreement but not by "broad" agreement. In particular for smaller, well-understood fixes, there typically is no "broad" agreement, but "silent agreement", as everybody is fine with a fix. Hence, we should not stop ourselves *unless needed*. A discussion is fine *and needed* **for API changes**. A discussion *before showing code* for small fixes makes no sense at all and makes things overly complex, as how would you discuss whether it is fine to fix a code line without showing that codeline? > > I think you may be over reading this. When someone sends mail with a proposal for some feature or API then there is no obligation for anyone to respond. Lack of a timely response should not be interpreted as agreement with the proposal. The phrase "The absence of dissent is not the presence of consent" comes to mind. It may be annoying to not get a timely response from maintainers in specific areas but this shouldn't mean it's time to create a PR and start reviewing code and changes. Code first and "code is king" may be how many projects work but here, and especially for APIs, the code will often have negative value because it distracts from the bigger questions. > > One thing that has kinda worked on a few occasions is where a PR is created with an API and no implementation code, the intention being to focus on the API and avoid the distraction of folks trying to micro optimize before it's clear whether the proposal will get traction. Maybe the text in the guide should be more clear that changes can sit anywhere on a long scale from "trivial one-line bug fixes" to "suggestions of entirely new APIs", and that this newly added comment applies to changes on the heavier side of this scale, rather than the lighter and trivial fixes. For these, I agree with @mkarg that it might be better just to present a PR (especially if there already exists a JBS issue with a clear specification of what is wrong) than to clog the mailing lists with unnecessary discussion about the merits of such a fix. Where to draw the line then is the big question... The guide can certainly ask people to rather err on the side of socializing the idea first, rather than publishing PRs. ------------- PR Review Comment: https://git.openjdk.org/guide/pull/150#discussion_r2077392705 From duke at openjdk.org Sun May 11 09:39:02 2025 From: duke at openjdk.org (Markus KARG) Date: Sun, 11 May 2025 09:39:02 GMT Subject: RFR: Get agreement before PR In-Reply-To: <4OkBAwzccGghMfRzXwUJh53a18wzSL2IzNZayeKgwss=.87b55c46-38ec-4ae1-90aa-93e7d65a13ec@github.com> References: <4-cffFDlrnLyAvwl0Op1JoMnIY5VQJbR4BsWq-yjGWQ=.53c0ddba-4259-40df-b603-7ca113258739@github.com> <4OkBAwzccGghMfRzXwUJh53a18wzSL2IzNZayeKgwss=.87b55c46-38ec-4ae1-90aa-93e7d65a13ec@github.com> Message-ID: On Wed, 7 May 2025 11:14:34 GMT, Magnus Ihse Bursie wrote: >> I think you may be over reading this. When someone sends mail with a proposal for some feature or API then there is no obligation for anyone to respond. Lack of a timely response should not be interpreted as agreement with the proposal. The phrase "The absence of dissent is not the presence of consent" comes to mind. It may be annoying to not get a timely response from maintainers in specific areas but this shouldn't mean it's time to create a PR and start reviewing code and changes. Code first and "code is king" may be how many projects work but here, and especially for APIs, the code will often have negative value because it distracts from the bigger questions. >> >> One thing that has kinda worked on a few occasions is where a PR is created with an API and no implementation code, the intention being to focus on the API and avoid the distraction of folks trying to micro optimize before it's clear whether the proposal will get traction. > > Maybe the text in the guide should be more clear that changes can sit anywhere on a long scale from "trivial one-line bug fixes" to "suggestions of entirely new APIs", and that this newly added comment applies to changes on the heavier side of this scale, rather than the lighter and trivial fixes. > > For these, I agree with @mkarg that it might be better just to present a PR (especially if there already exists a JBS issue with a clear specification of what is wrong) than to clog the mailing lists with unnecessary discussion about the merits of such a fix. > > Where to draw the line then is the big question... The guide can certainly ask people to rather err on the side of socializing the idea first, rather than publishing PRs. Looking back at the 30 years I am contributing to / leading lots of open source projects, my experience is that **for all non-API / non-spec changes** (except *very large* code changes) it is often easier to explain the target or a PR *with actual code at hand*. For example, "hidden constraints and assumptions, stability and quality, maintainability, compatibility, and conformance to specifications" rather often can get *better* identified if a draft PR *exists already*. *Draft*-PRs are exactly the vehicly that what would fill the gap missing in the process here. Having said that, I think the line should be drawn here: * *Draft*-PRs MAY be filed *without* broad concensus on the mailing list, e. g. to have "some code at hand" for the sake of *getting* that broad concensus by referencing them from mailing list postings. *This helps getting a better understanding of the actual intent of small implementation-only changes, which are often hard to express **unambiguously** in plain text.* * PRs MAY be filed *without* broad concensus on the mailing list *iff* these are neither API changes / spec changes, neither are "very large" code changes. *This helps getting internal refactorings etc. done rather quickly instead of queing them for weeks and months.* * API changes and spec changes need a CSR anyways, which *implies* a discussion on the mailing list anyways. * "very large" code changes MUST get announced on the mailing list upfront, and all committers are encouraged to actively comment on them as soon as possible, without a timely restriction. * *All other* PRs SHOULD get announced on the mailing list, but it still SHOULD be allowed to file time *before* there is broad concensus on the mailing list. This allows "implied silent approval" which de facto is an existing phenomenon and should not get ignored. ------------- PR Review Comment: https://git.openjdk.org/guide/pull/150#discussion_r2083450265 From duke at openjdk.org Sun May 11 09:39:02 2025 From: duke at openjdk.org (Markus KARG) Date: Sun, 11 May 2025 09:39:02 GMT Subject: RFR: Get agreement before PR In-Reply-To: References: Message-ID: On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson wrote: > Added a note on getting proper agreement on a change before creating a PR for it. src/guide/contributing-to-an-open-jdk-project.md line 65: > 63: ### 3. Find a Sponsor > 64: > 65: Socializing your change on the mailing lists also prevents the surprise that would otherwise make the community choke on their morning coffee when they see a huge patch in a new, unknown PR. As a new developer in the community you'll need to make a few friends that agree with your change. There are many good reasons to make friends, but the one relevant here is that for your first changes you'll need a [Sponsor](https://openjdk.org/bylaws#sponsor) to facilitate the integration of your work. The [Sponsor](https://openjdk.org/bylaws#sponsor) will perform any number of administrative tasks like JBS updates, additional testing, etc. It's usual for a [Sponsor](https://openjdk.org/bylaws#sponsor) to also be a reviewer of a change and thus familiar with it, but it's not a requirement. Imho "for your first changes" is misleading here. I contributed lots of commits, but still do need a sponsor even after years. We should find a wording which does not give the impression that contributing many commits over several years will change anything on the fact that a sponsor *still* is mandatory for each PR. ------------- PR Review Comment: https://git.openjdk.org/guide/pull/150#discussion_r2083467228 From jwilhelm at openjdk.org Tue May 13 22:10:04 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 13 May 2025 22:10:04 GMT Subject: RFR: Get agreement before PR In-Reply-To: References:

Message-ID: On Sun, 11 May 2025 09:36:50 GMT, Markus KARG wrote: >> Added a note on getting proper agreement on a change before creating a PR for it. > > src/guide/contributing-to-an-open-jdk-project.md line 65: > >> 63: ### 3. Find a Sponsor >> 64: >> 65: Socializing your change on the mailing lists also prevents the surprise that would otherwise make the community choke on their morning coffee when they see a huge patch in a new, unknown PR. As a new developer in the community you'll need to make a few friends that agree with your change. There are many good reasons to make friends, but the one relevant here is that for your first changes you'll need a [Sponsor](https://openjdk.org/bylaws#sponsor) to facilitate the integration of your work. The [Sponsor](https://openjdk.org/bylaws#sponsor) will perform any number of administrative tasks like JBS updates, additional testing, etc. It's usual for a [Sponsor](https://openjdk.org/bylaws#sponsor) to also be a reviewer of a change and thus familiar with it, but it's not a requirement. > > Imho "for your first changes" is misleading here. I contributed lots of commits, but still do need a sponsor even after years. We should find a wording which does not give the impression that contributing many commits over several years will change anything on the fact that a sponsor *still* is mandatory for each PR. If I'm not mistaken you have contributed 16 changes over the last three and a half year. I haven't looked at them in detail, but provided these aren't trivial changes or changes that caused more harm than good, you should be eligible for a Committer role in the JDK project and thereby not be needing a Sponsor. ------------- PR Review Comment: https://git.openjdk.org/guide/pull/150#discussion_r2087701866 From jwilhelm at openjdk.org Tue May 13 23:12:11 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 13 May 2025 23:12:11 GMT Subject: RFR: Get agreement before PR In-Reply-To: References: Message-ID: <33-0tCuKSbh1z15WyrvefOEE_zRuuXF9gS1UvDa1SYI=.7ad7beae-fd4e-4e7e-beab-e619c75da7c9@github.com> On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson wrote: > Added a note on getting proper agreement on a change before creating a PR for it. I think we need to take a step back and look at who the intended audience is and how the Developers' Guide is intended to be used. The primary target audience is developers who want to start contributing to OpenJDK and have little or no previous experience of doing so. Sure, many parts of the guide are step-by-step descriptions of how to do various things in JBS etc, and are likely relevant to experienced contributors as well, as many things like backing out a change and such aren't things you do on a daily basis. But still, the part of the guide we are currently looking at is unlikely to be read by someone who has been around long enough to become Committer for instance. So this is as much about setting expectations as it is about detailing how people should work. Many OpenJDK developers know from experience that there is an implicit broad consensus for some types of changes in some areas of the code. Many OpenJDK developers know from discussions through other channels that there is a broad consensus for specific changes in specific areas - e.g. something might have been discussed at a committers workshop or similar venue. Some changes get broad consensus through local discussions at an office where several OpenJDK developers work together on a daily basis or through project team meetings. There are many ways to get a broad consensus but in reality only the mailing list is the option available to someone who is an unknown independent developer who wish to join the OpenJDK community. This is why the mailing list is presented as the viable option in this text. This should not be interpreted as "lack of discussion on the mailing list = lack of discussion". Trust me, even small changes made by experienced developers will get shot down if they have n't been discussed and agreed on before the PR is presented. The text here could be phrased differently to cover more ways to get consensus, or explain various exceptions to the guidelines, but I see no benefit of doing so. We don't want a developer to get the impression that a first-timer can show up with a PR with a small one-line bug fix and just get a quick fix into the code. That's not how we work. I'm sure you understand why, but for reference I'll put this link here: https://openjdk.org/guide/#why-is-my-change-rejected When it comes to replying to PRs or mail threads in a timely maner one must be realistic and understand that * most OpenJDK developers have limited time * most experienced OpenJDK developers are actively working in some specific project and are unlikely to have time for changes not related to that specific project * most experienced OpenJDK developers are employed by a company and may be constrained by company policies dictating what paid company time should be spent on * no experienced OpenJDK developer will look at an implementation of a solution to a problem before being convinced that it's the right problem to solve, and it's the right solution to that problem * no experienced OpenJDK developer will approve a change without spending significant time on understanding the affected area, the change, and all its implications ------------- PR Comment: https://git.openjdk.org/guide/pull/150#issuecomment-2878154106 From jwilhelm at openjdk.org Tue May 13 23:20:41 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 13 May 2025 23:20:41 GMT Subject: RFR: More testing Message-ID: * RN-Deprecated example should link to an issue with the RN-Deprecated label * PRs should list what testing has been done * Make sure to test the final version of a fix ------------- Commit messages: - More testing Changes: https://git.openjdk.org/guide/pull/151/files Webrev: https://webrevs.openjdk.org/?repo=guide&pr=151&range=00 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/guide/pull/151.diff Fetch: git fetch https://git.openjdk.org/guide.git pull/151/head:pull/151 PR: https://git.openjdk.org/guide/pull/151 From iris at openjdk.org Wed May 14 02:06:02 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 14 May 2025 02:06:02 GMT Subject: RFR: More testing In-Reply-To: References: Message-ID: On Tue, 13 May 2025 23:16:45 GMT, Jesper Wilhelmsson wrote: > * RN-Deprecated example should link to an issue with the RN-Deprecated label > * PRs should list what testing has been done > * Make sure to test the final version of a fix Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/guide/pull/151#pullrequestreview-2838518926 From jwilhelm at openjdk.org Wed May 14 23:04:03 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 14 May 2025 23:04:03 GMT Subject: RFR: More testing In-Reply-To: References: Message-ID: On Tue, 13 May 2025 23:16:45 GMT, Jesper Wilhelmsson wrote: > * RN-Deprecated example should link to an issue with the RN-Deprecated label > * PRs should list what testing has been done > * Make sure to test the final version of a fix Thank you Iris! ------------- PR Comment: https://git.openjdk.org/guide/pull/151#issuecomment-2881782000 From jwilhelm at openjdk.org Wed May 14 23:04:03 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 14 May 2025 23:04:03 GMT Subject: Integrated: More testing In-Reply-To: References: Message-ID: On Tue, 13 May 2025 23:16:45 GMT, Jesper Wilhelmsson wrote: > * RN-Deprecated example should link to an issue with the RN-Deprecated label > * PRs should list what testing has been done > * Make sure to test the final version of a fix This pull request has now been integrated. Changeset: acf9989a Author: Jesper Wilhelmsson URL: https://git.openjdk.org/guide/commit/acf9989ad9d0f7a10fe05ad2885a6d5563c718eb Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod More testing Reviewed-by: iris ------------- PR: https://git.openjdk.org/guide/pull/151 From ihse at openjdk.org Fri May 16 09:20:06 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 16 May 2025 09:20:06 GMT Subject: RFR: Get agreement before PR In-Reply-To: References: Message-ID: On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson wrote: > Added a note on getting proper agreement on a change before creating a PR for it. Maybe you can take your last comment, rephrase it and shorten it somewhat, and include it in the guide? At least to me, having *reasons* for specific rules makes them easier to understand, especially in a case like this where we might seem hard and unwelcoming otherwise. ------------- PR Comment: https://git.openjdk.org/guide/pull/150#issuecomment-2886141421 From aph-open at littlepinkcloud.com Wed May 21 08:20:49 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 21 May 2025 09:20:49 +0100 Subject: Where to put supplementary docs? In-Reply-To: References:

Message-ID: On 4/24/25 16:26, Robbin Ehn wrote: > One major challenge with the other places (CR, JBS, PR, wiki), is that > they don't handle versioning. (naturally) > This means the code can't safely refer to, e.g., a wiki page, as that > page may describe a newer version. > If a developer is working in JDK 11 or in the Loom project, they need > the relevant documentation for that specific fork/branch. Exactly this. Also, as soon as a document is no longer relevant, it can be removed from the JDK source tree. -- 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