Set a fix version for non-duplicate issues solved by another issue

Development
#1

Hi everyone,

it happens that a bug is fixed by an improvement or another bug fix either intentionally, e.g., because it turns out they have the same reason or a larger improvement has been implemented to fix several issues at once, or unintentionally, because the developer fixing an issue wasn’t aware of this issue. In these cases, we normally close the bug as “solved by” and don’t set a “fix version”. I propose to change this and to set a “fix version” if the closed bug (“this” issue") isn’t a duplicate of the “other” issue from a user’s point of view. For non-security issues, the precise definition of “duplicate” is up to the person closing the issue. For security issues, a fix version and the correct affects version must be set on “this” issue if one of the following is true for the “other” issue that solved it:

  • The “other” issue is not a security issue.
  • The “other” security issue has less or a different impact than “this” issue on confidentiality, integrity or availability (like exposing less data or other data).
  • The “other” security issue is more difficult to exploit and might not be exploitable in cases where “this” issue is exploitable (possibly depending on configuration, right setup, attacker access or a different kind of user interaction).
  • There are XWiki versions on which “this” issue but not the “other” issue is exploitable.

In these cases, a security advisory must also exist that describes “this” issue (can be the same advisory as the one for the “other” issue as long as covers both issues).

The reason for these conditions is that it should be possible with a query on Jira to get all security issues that affect a certain version of XWiki to be able to accurately determine the maximum impact on security for a specific XWiki instance. For non-security issues, it can still be interesting for users to be able to easily see if a certain bug they might have experienced has been fixed in an upgrade they are performing or planning.

Thank you very much for your opinions.

[Edit] My proposal is to apply this policy from now on, I don’t think there is a need to systematically fix old issues but we could of course do a query to find potentially affected security issues.

#2

+1

#3

+1

For reference, the current development practice is:

Issues that are closed with “Won’t fix”, “Duplicate”, “Cannot reproduce”, 'Solved By" or “Incomplete” must have a “Fix For” field set to “unknown” so that they don’t appear in the Release Notes, as JIRA doesn’t make the distinction visible and this causes confusion.

From Development Practices - XWiki

#4

+1
thanks

#5

+1 Thanks

#6

+1

#7

Thanks Michael.

I find the proposal too complex to implement (The mere fact that it takes so many lines to describe it is an indication of the complexity IMO - there are at least 5 conditions to respect! ;)).

I would propose to do something much simpler, which is simply, that from now on, to always put a fix version for issues closed with “Solved by”. Ofc this means that in the RN of a given version there’ll be issues without commits (or said differently that a commit can have more than 1 issue related to it), but that’s the case with what you propose anyway and I don’t think it’s a major issue.

In short, I’m proposing to change this rule:

Current text:

Issues that are closed with “Won’t fix”, “Duplicate”, “Cannot reproduce”, 'Solved By" or “Incomplete” must have a “Fix For” field set to “unknown” so that they don’t appear in the Release Notes, as JIRA doesn’t make the distinction visible and this causes confusion.

New text:

Issues that are closed with “Won’t fix”, “Duplicate”, “Cannot reproduce”, “Incomplete” must have a “Fix Version” field set to “unknown” so that they don’t appear in the Release Notes, as JIRA doesn’t make the distinction visible and this causes confusion.

Note that “Solved by” issues must have a “Fix Version” set so that users can easily query JIRA to find in which version an issue has been fixed (rather than have to look in linked issues). This is useful for example for security issues which are closed as “Solved by” when they are fixed by other non-security issues. It’s also simpler for users to understand what’s been fixed in a given release, since the “Solved by” issue is usually described from a user perspective while the fixing issue is often more technical and more indirectly related.

Another advantage of this strategy is that it’s easy to query JIRA for “Solved by” issues that are missing a “Fix version” (after the date of effect for this proposal) and to fix them.

WDYT?

Thanks

#8

I’m fine with the new proposal, +1. We have currently 242 issues with resolution = "Solved By" AND fixVersion is EMPTY . I’m not sure we want to set a fix version for all of them, but I would suggest to at least fix the 11 of them that have a “security” label.

I mean in theory, everything that doesn’t fulfill the criteria I mentioned should probably be closed as a duplicate and not as “Solved by”, anyways, so in the end I think the proposals are not that different.

#9

I’m fine with the always proposal, too.

#10

The proposal has been documented on Development Practices - XWiki and is effective starting now! :slight_smile:

Feel free to update existing jiras.

1 Like