Project

General

Profile

Feature #689

Add field(s) for reporting the version a bug is detected in

Added by Teemu Murtola about 10 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
High
Category:
Redmine
Target version:
-
Close

Description

I think that we really should add a custom field for bugs that would contain the version in which a bug is detected. The format of this field should be discussed: should it be a selection from a fixed list, or a free-form field. This is affected by whether we want to be able to extract useful statistics out of the field. It's also possible to have several fields, e.g., one for the version detected in, and another one for all other affected versions. It all depends on the long-term plans on whether some kind of statistics are of interest.

As long as this is not resolved, work just keeps piling up on the poor soul who gets assigned issue #628.


Related issues

Related to Support Platforms - Task #633: Expand range of versions available when reporting bugsClosed
Blocks Support Platforms - Task #628: Roadmap of the main Gromacs project needs fixingClosed

History

#1 Updated by Mark Abraham about 10 years ago

Agreed.

I think we need to log both the version in which it was detected, and the version in which a fix will appear.

A problem in a git branch (e.g. in pre-release testing) needs to be able to identified as such, but the actual branch and/or commit hash can be in the description.

We need to bring this to the attention of someone who can act - Rossen? I have no idea.

#2 Updated by Teemu Murtola about 10 years ago

  • Assignee set to Rossen Apostolov

Mark Abraham wrote:

I think we need to log both the version in which it was detected, and the version in which a fix will appear.

The Target version should be used for the latter to take full advantage of Redmine's features.

A problem in a git branch (e.g. in pre-release testing) needs to be able to identified as such, but the actual branch and/or commit hash can be in the description.

If the field is free-form, it's easy to just write there the development version like 5.0-dev-abcdef, but a free-form field may not be ideal if it has to be searchable. But as you said, any details that don't fit into the format chosen for the field can be put in the description.

We need to bring this to the attention of someone who can act - Rossen? I have no idea.

To me, it seems that the whole Redmine project has been a bit forgotten; the previous post by anyone than me or Mark is from more than two weeks ago, and the issues would really benefit from someone else's contribution as well. Will assign this to Rossen now (he probably at least has the privileges to change the custom fields), but if it is true that the issues that are now in this project here really haven't got anyone's attention in the past two weeks, we might need to rethink the policy of not assigning things to anyone by default.

#3 Updated by Rossen Apostolov about 10 years ago

I added a couple of new fields.

"Detected in version" and "Affected versions" both of which are required and apply to all projects. The list is for versions:

3.1
3.2
3.3
4.0
4.0.7
4.5.1
4.5.2
4.5.3
current git master

For "current git master" we'll need a requirement to specify the commit but I don't know how this could be enforced.

Also, do we need the old 3.x versions in the list? I would say keep only 3.3, 4.0.7 and 4.5.3.

I also added "Target version" with a list of choices 4.6, 5.0 and 6.0. This field applies to bugs, features and tasks but is not required because this can be decided at later stage after filing the issue.

#4 Updated by Teemu Murtola about 10 years ago

Rossen Apostolov wrote:

I added a couple of new fields.

"Detected in version" and "Affected versions" both of which are required and apply to all projects. The list is for versions:

There can be more than one "Affected version"; either the field has to be multi-choice (which Redmine might not allow), free-format, or it should be renamed to something like "First affected version".

For "current git master" we'll need a requirement to specify the commit but I don't know how this could be enforced.

I don't think we need to strictly enforce it, but we could have instructions, e.g., on the front page that would ask people to enter that information in the description (see issue #687).

Also, do we need the old 3.x versions in the list? I would say keep only 3.3, 4.0.7 and 4.5.3.

I don't think it's that critical to have old versions there; it's always possible to add them later if the need arises (e.g., when working on issue #628).

I also added "Target version" with a list of choices 4.6, 5.0 and 6.0. This field applies to bugs, features and tasks but is not required because this can be decided at later stage after filing the issue.

I think that a custom field named "Target version" is not the right solution. There is already a field named "Target version" provided by default by Redmine, and that field is used for constructing, e.g., the roadmaps. I now added 5.0 to the versions configured for the Gromacs project, and shared that with all other subprojects. However, the list should be cleaned up (there should be no git master or CVS there), but that is blocked by issue #628. We could also have a place-holder version with something like "future development" or "5.x" for tasks that are decided to be postponed after all the explicitly listed versions. But that can also be added when the need arises.

#5 Updated by Szilárd Páll about 9 years ago

  • Category set to Redmine

Not trying to flame, but I want to point out one important thing. Looking at the past year's list of bugs, it becomes obvious that in most cases the "Known affected versions" free-form text field is empty. IMO this is a serious issue, especially that in many cases not only the detected/affected version is unknown, but also the fixing commit lacks the issue ID.

I think we should improve this by:
  • finding a reasonable solution to enforce at least a "detected in" version to be picked from a fixed list;
  • being more strict about the bugfix commit format requirements.

#6 Updated by Szilárd Páll over 8 years ago

It's annoying (and yes, it pisses me off) that this issue is being blatantly ignored even though it is very important and most people agreed on the need for improvements.

In fact, most, if not all, redmine-related issues have been ignored for at least the last year, neither has been progress nor have these issues been reassigned or closed.

#7 Updated by Szilárd Páll over 8 years ago

  • Assignee deleted (Rossen Apostolov)

#8 Updated by Rossen Apostolov over 8 years ago

Is it clear

1) exactly what fields are needed?
2) what type - free text or fixed selection list?
3) should they be optional or not?
4) what entries go in a fixed selection list?

#9 Updated by Mark Abraham almost 8 years ago

The ability for a user to report the issue in multiple versions is useful.

A free-form text field for version reporting seems not to work.

I don't think we should require a version for an issue - there may be general things that are not particular to any version (or common to all).

I suggest we populate the version list with known and anticipated-soon version numbers, something to indicate "after the next major release", and "blue-sky future".

So right now we should have "tips" that are
4.5.7
4.6.2
5.x
future

#10 Updated by Teemu Murtola almost 8 years ago

Mark Abraham wrote:

A free-form text field for version reporting seems not to work.

If the problem is that the field is usually empty, then I think that making it required is the first solution. The only problem I see with a free-form text field is that it is not very easy to extract statistics, but I don't think that this ranks particularly high on our list of requirements... Free-form text has a lot of benefits as well, e.g., allowing one to identify development versions etc.

I don't think we should require a version for an issue - there may be general things that are not particular to any version (or common to all).

But for bugs, we probably should require one to identify which version the report comes from. For other types of issues, I don't see a point in having such a field at all.

I suggest we populate the version list with known and anticipated-soon version numbers, something to indicate "after the next major release", and "blue-sky future".

It is not possible that someone finds a bug in a "blue-sky future" release before it is even planned. ;) So if we want to have a version list, it should contain all released versions, and preferably also development versions of these (so it explodes very easily).

The use for the Target version field is a different story, but that definitely should not be used for the version reporting discussed here.

#11 Updated by Rossen Apostolov almost 8 years ago

  • Status changed from New to Accepted
  • Assignee set to Rossen Apostolov

After the discussion today we included two fields: "Affected version" - required, fixed drop down list that corresponds to all versions as defined in the project; and "Affected version - extra info" - free form text, optional.

#12 Updated by Rossen Apostolov almost 8 years ago

  • Status changed from Accepted to In Progress

#13 Updated by Rossen Apostolov almost 8 years ago

  • Status changed from In Progress to Fix uploaded

#14 Updated by Rossen Apostolov almost 8 years ago

  • Status changed from Fix uploaded to Resolved

#15 Updated by Rossen Apostolov almost 8 years ago

  • Status changed from Resolved to Feedback wanted

#16 Updated by Teemu Murtola almost 8 years ago

Rossen Apostolov wrote:

After the discussion today we included two fields: "Affected version" - required, fixed drop down list that corresponds to all versions as defined in the project; and "Affected version - extra info" - free form text, optional.

Could you please provide a rationale for this choice, and better descriptions (best included directly in http://www.gromacs.org/Developer_Zone/Redmine) for how to actually use these fields? I think that "Affected version" -> "Version found in" and "Affected version - extra info" -> "Affected versions" would be much more unambiguous (if this is how you planned these fields to be used).

For the record, it seems that the previous "Known affected versions" is now "Affected version - extra info" (i.e., the field got renamed). This is reasonable, but just documented it here...

A list of issues noticed so far (with a few minutes of browsing Redmine):
  • Why is "Affected version - extra info" available for a Task, but "Affected version" isn't? Especially with the current naming this is confusing. Neither of them is available for Features.
  • "Affected version" is now mandatory for bugs in the Support Platforms project, but there are actually no available versions -> impossible to submit bugs here. I would remove both fields from this project.
  • As I said in my previous comment, it doesn't make sense to have an option for "Bug found in the distant future", or for several other of the current choices. Also, the list of choices is in quite a random order. Maybe a topic for separate clean-up, but as it is now, I don't see particular value in the drop-down list vs. a required free text field. The instructions should also state what to put in the field if one founds a bug in, e.g., 4.6.3-dev, both in the case that it exists in 4.6.2 and that it doesn't.

#17 Updated by Rossen Apostolov almost 8 years ago

Teemu Murtola wrote:

Could you please provide a rationale for this choice, and better descriptions (best included directly in http://www.gromacs.org/Developer_Zone/Redmine) for how to actually use these fields? I think that "Affected version" -> "Version found in" and "Affected version - extra info" -> "Affected versions" would be much more unambiguous (if this is how you planned these fields to be used).

"Known affected versions" were renamed to "Affected version - extra info" because for already created fields one can not change their type (e.g. from free text to drop-down) but only rename them. And if "Known affected" was removed we'd loose the information in that field. I don't mind renaming them as you suggest.

For the record, it seems that the previous "Known affected versions" is now "Affected version - extra info" (i.e., the field got renamed). This is reasonable, but just documented it here...

A list of issues noticed so far (with a few minutes of browsing Redmine):
  • Why is "Affected version - extra info" available for a Task, but "Affected version" isn't? Especially with the current naming this is confusing. Neither of them is available for Features.

Right, there are still parts that need to be polished. I'll fix that. Shall we have the "version found in" and "affected version" only for bugs and maybe tasks also? Does it make sense for features?

  • "Affected version" is now mandatory for bugs in the Support Platforms project, but there are actually no available versions -> impossible to submit bugs here. I would remove both fields from this project.

OK.

  • As I said in my previous comment, it doesn't make sense to have an option for "Bug found in the distant future", or for several other of the current choices. Also, the list of choices is in quite a random order. Maybe a topic for separate clean-up, but as it is now, I don't see particular value in the drop-down list vs. a required free text field. The instructions should also state what to put in the field if one founds a bug in, e.g., 4.6.3-dev, both in the case that it exists in 4.6.2 and that it doesn't.

There were different opinions about whether the "affected version (version found in)" should be a dropdown or free text. If dropdown, one can use either a manually generated list, or an automated list of all registered versions (the current implementation). The registered versions are losted in alphabetical order but we've put the most recent versions at the top for quicker selection.

The setup now requests that the "affected version" is required and selected from the dropdown (in your example that would be 4.6.3-dev), while additional versions (4.6.2) can be added later either by the reporter or the developer taking care of the bug.

We've talked about that for such a long time :) We should either stay with something acceptable for those fields or make a poll and close the case :)

#18 Updated by Teemu Murtola almost 8 years ago

Rossen Apostolov wrote:

Teemu Murtola wrote:

A list of issues noticed so far (with a few minutes of browsing Redmine):
  • Why is "Affected version - extra info" available for a Task, but "Affected version" isn't? Especially with the current naming this is confusing. Neither of them is available for Features.

Right, there are still parts that need to be polished. I'll fix that. Shall we have the "version found in" and "affected version" only for bugs and maybe tasks also? Does it make sense for features?

I don't think either of them makes much sense for features. The Target Version is the version where the feature is (planned to be) implemented; I don't think there is any need for other version information there. Also for tasks, I don't think there is usually need for more than the Target Version field. It may be useful to be able to specify, e.g., for refactoring tasks the version where the refactoring need was identified, in the case the task remains open for a prolonged amount of time (so that it is easier to understand the text in the context of the code that it applies to). But that probably doesn't warrant a mandatory version field for tasks.

  • As I said in my previous comment, it doesn't make sense to have an option for "Bug found in the distant future", or for several other of the current choices. Also, the list of choices is in quite a random order. Maybe a topic for separate clean-up, but as it is now, I don't see particular value in the drop-down list vs. a required free text field. The instructions should also state what to put in the field if one founds a bug in, e.g., 4.6.3-dev, both in the case that it exists in 4.6.2 and that it doesn't.

There were different opinions about whether the "affected version (version found in)" should be a dropdown or free text. If dropdown, one can use either a manually generated list, or an automated list of all registered versions (the current implementation). The registered versions are losted in alphabetical order but we've put the most recent versions at the top for quicker selection.

The setup now requests that the "affected version" is required and selected from the dropdown (in your example that would be 4.6.3-dev), while additional versions (4.6.2) can be added later either by the reporter or the developer taking care of the bug.

This is what I would have done, if the field were free text. Unfortunately, "4.6.3-dev" is not a valid choice... And I'm not sure we want to have a massive amount of -dev options in the dropdown list (and thus possibly also on the Roadmap page, which currently has, e.g., roadmap for N/A).

We've talked about that for such a long time :) We should either stay with something acceptable for those fields or make a poll and close the case :)

I don't care that much; I can simply refrain from using the system for cases that I find too annoying. I'm just trying to bring up issues now that they can still be fixed with relatively little work. And before making a poll (not sure whether that is the best approach, though), it would really be useful to document somewhere the arguments for the different options. Haven't seen so far that many justifications for it being a fixed list selection...

#19 Updated by Rossen Apostolov almost 8 years ago

Teemu Murtola wrote:

I don't think either of them makes much sense for features. The Target Version is the version where the feature is (planned to be) implemented; I don't think there is any need for other version information there. Also for tasks, I don't think there is usually need for more than the Target Version field. It may be useful to be able to specify, e.g., for refactoring tasks the version where the refactoring need was identified, in the case the task remains open for a prolonged amount of time (so that it is easier to understand the text in the context of the code that it applies to). But that probably doesn't warrant a mandatory version field for tasks.

I cleaned up the fields. Now tasks and features have only target version, while bugs have also affected version field. I've removed "start date", "due date", "estim. time" and "%done" from all. (this wasn't possible in the old redmine)

  • As I said in my previous comment, it doesn't make sense to have an option for "Bug found in the distant future", or for several other of the current choices. Also, the list of choices is in quite a random order. Maybe a topic for separate clean-up, but as it is now, I don't see particular value in the drop-down list vs. a required free text field. The instructions should also state what to put in the field if one founds a bug in, e.g., 4.6.3-dev, both in the case that it exists in 4.6.2 and that it doesn't.

There were different opinions about whether the "affected version (version found in)" should be a dropdown or free text. If dropdown, one can use either a manually generated list, or an automated list of all registered versions (the current implementation). The registered versions are losted in alphabetical order but we've put the most recent versions at the top for quicker selection.

The setup now requests that the "affected version" is required and selected from the dropdown (in your example that would be 4.6.3-dev), while additional versions (4.6.2) can be added later either by the reporter or the developer taking care of the bug.

This is what I would have done, if the field were free text. Unfortunately, "4.6.3-dev" is not a valid choice... And I'm not sure we want to have a massive amount of -dev options in the dropdown list (and thus possibly also on the Roadmap page, which currently has, e.g., roadmap for N/A).

We've talked about that for such a long time :) We should either stay with something acceptable for those fields or make a poll and close the case :)

I don't care that much; I can simply refrain from using the system for cases that I find too annoying. I'm just trying to bring up issues now that they can still be fixed with relatively little work. And before making a poll (not sure whether that is the best approach, though), it would really be useful to document somewhere the arguments for the different options. Haven't seen so far that many justifications for it being a fixed list selection...

I'm personally for a single, required, free text field for the versions. At a meeting some time ago we discussed to have a dropdown but it seems that it doesn't work so well. So I'd rather have the free text and close this discussion.

#20 Updated by Rossen Apostolov almost 8 years ago

One of the objections against a single, free form and required field is that users might write gibberish in it. We don't know if that will actually happen, and even if it does it will be easy to fix when a "New" issue is reviewed for the first time.

A dropdown that doesn't contain the specific version will expect the user to include it in the additional "Affected version - extra info" field. But that field is not required thus less likely to be used an we'll get the same info as if there was just one required free text field.

I'll move the information from the current "Affected versions" (dropdown) into the "Affected versions - extra info" (free text), remove the former and rename the latter to "Affected versions".

Then close this issue for now. Lets use it like that for a while and see how it works.

#21 Updated by Rossen Apostolov over 6 years ago

  • Status changed from Feedback wanted to Resolved

It seems that the current system works reasonably well, i.e. with "Affected version (dropdown)" compulsory, and "Affected version - extra info (free text)" not.

Resolving the issue for now.

#22 Updated by Szilárd Páll almost 4 years ago

  • Status changed from Resolved to Closed

it seems we're settled on the current setup, so I'll close this.

Also available in: Atom PDF