RFR: Addition of a causes link type [v4]

Roger Calnan duke at openjdk.org
Tue Jan 21 18:29:30 UTC 2025


On Wed, 4 Dec 2024 02:30:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates from feedback
>
> src/guide/jbs-jdk-bug-system.md line 269:
> 
>> 267: ‘blocks’ - when a fix is broken down into a number of parts the ‘blocks’ link should be used to ensure they are all fixed before the main issue is considered resolved - see [implementing large changes](#implementing-large-changes]
>> 268: 
>> 269: ‘relates to’ - there are no rules as to when or why to create a relates link apart from not duplicating an existing “duplicated by”, ‘backported by’, ‘csr for’ or ‘blocked by’ links. In general, you should link any other issue that has a bearing on the situation where you feel the related issue should be reviewed in order to have a better understanding of what is going on
> 
> I'd also caution against excessive linking with "relates to" - for example, if a test fails you should not link every other issue with which this test has been previously been associated just because the same test was involved. The "relates to" issue should have some significance in relation to the cause and/or fix, for the current issue.
> 
> Note that it is often the case that a "relates to" situation is later determined to be a "duplicates" situation, in which case you have to manually delete the "relates to link" after Closing. (I wonder if JBS could automate that?)

reworded the section to make it clearer that relates links should have 'some significance' - agreed it would be useful if JIRA could update the relates link if it later used as a duplicate.  Will see if there is a way to spot this so that they might be manually cleaned up

-------------

PR Review Comment: https://git.openjdk.org/guide/pull/139#discussion_r1924191364


More information about the guide-dev mailing list