You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@infra.apache.org by "Matt Foley (JIRA)" <ji...@apache.org> on 2011/09/19 23:01:10 UTC
[jira] [Created] (INFRA-3937) Request for Hadoop Jiras: add custom
field "Target Version/s" [field type Version Picker]
Request for Hadoop Jiras: add custom field "Target Version/s" [field type Version Picker]
-----------------------------------------------------------------------------------------
Key: INFRA-3937
URL: https://issues.apache.org/jira/browse/INFRA-3937
Project: Infrastructure
Issue Type: Improvement
Security Level: public (Regular issues)
Components: JIRA
Reporter: Matt Foley
The Hadoop community actively maintains sustaining releases from non-trunk branches. As a result, critical bug fixes may be targeted for, and fixed in, multiple releases in different code lines. In Jira, the fact that 'fixVersion' is a Multi-Select type field partially accommodates this need. However, we also need a 'targetVersion' field. Here's why:
When making a release, one wants to query all Jiras marked fixed in this release.
Also, one wants to be able to query all open issues targeted for this release, but not yet fixed.
Neither of these queries can be made reliably if a bug fix is targeted for two or more versions, and fixed in some but not all.
Why current usage is deficient: Currently the Fix Versions is being overloaded. It is used to mean "should be fixed in" (target versions) while the bug is open, and "is fixed in" (fix versions) after the bug is resolved. That's fine if there's only one code branch in use. But if a fix is targeted for two branches A and B, and it's actually committed to A but not yet to B, there's no way to query the state of the fix. The bug appears open for both (or sometimes it's incorrectly closed for both!). You have to manually visit the individual bug report and review the SubversionCommits. This might be automatable, but it sure isn't easily expressed.
If we add a Target Versions field, then intent and completion can be separately marked (in the Target Versions and Fix Versions, respectively), and simple queries can clearly differentiate the cases.
This request applies to Jira products HADOOP, HDFS, and MAPREDUCE.
TargetVersion should be the same field type as FixVersion, apparently Version Picker or Multi-Select.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-3937) Request for Hadoop Jiras: add
custom field "Target Version/s" [field type Version Picker]
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108169#comment-13108169 ]
Doug Cutting commented on INFRA-3937:
-------------------------------------
Matt, I can add a 'Target Versions' field.
> Request for Hadoop Jiras: add custom field "Target Version/s" [field type Version Picker]
> -----------------------------------------------------------------------------------------
>
> Key: INFRA-3937
> URL: https://issues.apache.org/jira/browse/INFRA-3937
> Project: Infrastructure
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JIRA
> Reporter: Matt Foley
>
> The Hadoop community actively maintains sustaining releases from non-trunk branches. As a result, critical bug fixes may be targeted for, and fixed in, multiple releases in different code lines. In Jira, the fact that 'fixVersion' is a Multi-Select type field partially accommodates this need. However, we also need a 'targetVersion' field. Here's why:
> When making a release, one wants to query all Jiras marked fixed in this release.
> Also, one wants to be able to query all open issues targeted for this release, but not yet fixed.
> Neither of these queries can be made reliably if a bug fix is targeted for two or more versions, and fixed in some but not all.
> Why current usage is deficient: Currently the Fix Versions is being overloaded. It is used to mean "should be fixed in" (target versions) while the bug is open, and "is fixed in" (fix versions) after the bug is resolved. That's fine if there's only one code branch in use. But if a fix is targeted for two branches A and B, and it's actually committed to A but not yet to B, there's no way to query the state of the fix. The bug appears open for both (or sometimes it's incorrectly closed for both!). You have to manually visit the individual bug report and review the SubversionCommits. This might be automatable, but it sure isn't easily expressed.
> If we add a Target Versions field, then intent and completion can be separately marked (in the Target Versions and Fix Versions, respectively), and simple queries can clearly differentiate the cases.
> This request applies to Jira products HADOOP, HDFS, and MAPREDUCE.
> TargetVersion should be the same field type as FixVersion, apparently Version Picker or Multi-Select.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-3937) Request for Hadoop Jiras: add
custom field "Target Version/s" [field type Version Picker]
Posted by "Matt Foley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108145#comment-13108145 ]
Matt Foley commented on INFRA-3937:
-----------------------------------
If the reasons for this request are unclear in any way, please contact me.
If a custom field of type Version Picker can be added by Hadoop PMC members with Jira admin privs, without needing to involve Infra, please let me know, and I'll work with them instead.
Also, this request has support in the Hadoop developer community, please see the hadoop-common-dev mail archive, thread "[PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixes", started Sept. 15.
Thanks!
> Request for Hadoop Jiras: add custom field "Target Version/s" [field type Version Picker]
> -----------------------------------------------------------------------------------------
>
> Key: INFRA-3937
> URL: https://issues.apache.org/jira/browse/INFRA-3937
> Project: Infrastructure
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JIRA
> Reporter: Matt Foley
>
> The Hadoop community actively maintains sustaining releases from non-trunk branches. As a result, critical bug fixes may be targeted for, and fixed in, multiple releases in different code lines. In Jira, the fact that 'fixVersion' is a Multi-Select type field partially accommodates this need. However, we also need a 'targetVersion' field. Here's why:
> When making a release, one wants to query all Jiras marked fixed in this release.
> Also, one wants to be able to query all open issues targeted for this release, but not yet fixed.
> Neither of these queries can be made reliably if a bug fix is targeted for two or more versions, and fixed in some but not all.
> Why current usage is deficient: Currently the Fix Versions is being overloaded. It is used to mean "should be fixed in" (target versions) while the bug is open, and "is fixed in" (fix versions) after the bug is resolved. That's fine if there's only one code branch in use. But if a fix is targeted for two branches A and B, and it's actually committed to A but not yet to B, there's no way to query the state of the fix. The bug appears open for both (or sometimes it's incorrectly closed for both!). You have to manually visit the individual bug report and review the SubversionCommits. This might be automatable, but it sure isn't easily expressed.
> If we add a Target Versions field, then intent and completion can be separately marked (in the Target Versions and Fix Versions, respectively), and simple queries can clearly differentiate the cases.
> This request applies to Jira products HADOOP, HDFS, and MAPREDUCE.
> TargetVersion should be the same field type as FixVersion, apparently Version Picker or Multi-Select.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (INFRA-3937) Request for Hadoop Jiras: add custom
field "Target Version/s" [field type Version Picker]
Posted by "Matt Foley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Foley resolved INFRA-3937.
-------------------------------
Resolution: Fixed
Looks good, Doug, thanks! Re-indexing at an appropriate opportunity would be good; hopefully the new field will start showing up on old issues afterwards.
Resolving as requested.
> Request for Hadoop Jiras: add custom field "Target Version/s" [field type Version Picker]
> -----------------------------------------------------------------------------------------
>
> Key: INFRA-3937
> URL: https://issues.apache.org/jira/browse/INFRA-3937
> Project: Infrastructure
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JIRA
> Reporter: Matt Foley
>
> The Hadoop community actively maintains sustaining releases from non-trunk branches. As a result, critical bug fixes may be targeted for, and fixed in, multiple releases in different code lines. In Jira, the fact that 'fixVersion' is a Multi-Select type field partially accommodates this need. However, we also need a 'targetVersion' field. Here's why:
> When making a release, one wants to query all Jiras marked fixed in this release.
> Also, one wants to be able to query all open issues targeted for this release, but not yet fixed.
> Neither of these queries can be made reliably if a bug fix is targeted for two or more versions, and fixed in some but not all.
> Why current usage is deficient: Currently the Fix Versions is being overloaded. It is used to mean "should be fixed in" (target versions) while the bug is open, and "is fixed in" (fix versions) after the bug is resolved. That's fine if there's only one code branch in use. But if a fix is targeted for two branches A and B, and it's actually committed to A but not yet to B, there's no way to query the state of the fix. The bug appears open for both (or sometimes it's incorrectly closed for both!). You have to manually visit the individual bug report and review the SubversionCommits. This might be automatable, but it sure isn't easily expressed.
> If we add a Target Versions field, then intent and completion can be separately marked (in the Target Versions and Fix Versions, respectively), and simple queries can clearly differentiate the cases.
> This request applies to Jira products HADOOP, HDFS, and MAPREDUCE.
> TargetVersion should be the same field type as FixVersion, apparently Version Picker or Multi-Select.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-3937) Request for Hadoop Jiras: add
custom field "Target Version/s" [field type Version Picker]
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108181#comment-13108181 ]
Doug Cutting commented on INFRA-3937:
-------------------------------------
Should be there now, Matt. It doesn't show up on issues by default, but does show up in the 'Edit' page and in the 'Attach Files' pages.
Note that, unlike 'Fix Version' this doesn't list unreleased versions first, which is a pain, but that just seems to be the way user-configured version pickers work in Jira.
We need to re-index Jira before it'll be searchable, but that makes Jira unavailable. I'll talk to folks on #asfinfra before I do that.
If you're satisfied, please resolve this issue.
> Request for Hadoop Jiras: add custom field "Target Version/s" [field type Version Picker]
> -----------------------------------------------------------------------------------------
>
> Key: INFRA-3937
> URL: https://issues.apache.org/jira/browse/INFRA-3937
> Project: Infrastructure
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JIRA
> Reporter: Matt Foley
>
> The Hadoop community actively maintains sustaining releases from non-trunk branches. As a result, critical bug fixes may be targeted for, and fixed in, multiple releases in different code lines. In Jira, the fact that 'fixVersion' is a Multi-Select type field partially accommodates this need. However, we also need a 'targetVersion' field. Here's why:
> When making a release, one wants to query all Jiras marked fixed in this release.
> Also, one wants to be able to query all open issues targeted for this release, but not yet fixed.
> Neither of these queries can be made reliably if a bug fix is targeted for two or more versions, and fixed in some but not all.
> Why current usage is deficient: Currently the Fix Versions is being overloaded. It is used to mean "should be fixed in" (target versions) while the bug is open, and "is fixed in" (fix versions) after the bug is resolved. That's fine if there's only one code branch in use. But if a fix is targeted for two branches A and B, and it's actually committed to A but not yet to B, there's no way to query the state of the fix. The bug appears open for both (or sometimes it's incorrectly closed for both!). You have to manually visit the individual bug report and review the SubversionCommits. This might be automatable, but it sure isn't easily expressed.
> If we add a Target Versions field, then intent and completion can be separately marked (in the Target Versions and Fix Versions, respectively), and simple queries can clearly differentiate the cases.
> This request applies to Jira products HADOOP, HDFS, and MAPREDUCE.
> TargetVersion should be the same field type as FixVersion, apparently Version Picker or Multi-Select.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (INFRA-3937) Request for Hadoop Jiras: add custom
field "Target Version/s" [field type Version Picker]
Posted by "#asfinfra IRC Bot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
#asfinfra IRC Bot closed INFRA-3937.
------------------------------------
> Request for Hadoop Jiras: add custom field "Target Version/s" [field type Version Picker]
> -----------------------------------------------------------------------------------------
>
> Key: INFRA-3937
> URL: https://issues.apache.org/jira/browse/INFRA-3937
> Project: Infrastructure
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JIRA
> Reporter: Matt Foley
>
> The Hadoop community actively maintains sustaining releases from non-trunk branches. As a result, critical bug fixes may be targeted for, and fixed in, multiple releases in different code lines. In Jira, the fact that 'fixVersion' is a Multi-Select type field partially accommodates this need. However, we also need a 'targetVersion' field. Here's why:
> When making a release, one wants to query all Jiras marked fixed in this release.
> Also, one wants to be able to query all open issues targeted for this release, but not yet fixed.
> Neither of these queries can be made reliably if a bug fix is targeted for two or more versions, and fixed in some but not all.
> Why current usage is deficient: Currently the Fix Versions is being overloaded. It is used to mean "should be fixed in" (target versions) while the bug is open, and "is fixed in" (fix versions) after the bug is resolved. That's fine if there's only one code branch in use. But if a fix is targeted for two branches A and B, and it's actually committed to A but not yet to B, there's no way to query the state of the fix. The bug appears open for both (or sometimes it's incorrectly closed for both!). You have to manually visit the individual bug report and review the SubversionCommits. This might be automatable, but it sure isn't easily expressed.
> If we add a Target Versions field, then intent and completion can be separately marked (in the Target Versions and Fix Versions, respectively), and simple queries can clearly differentiate the cases.
> This request applies to Jira products HADOOP, HDFS, and MAPREDUCE.
> TargetVersion should be the same field type as FixVersion, apparently Version Picker or Multi-Select.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira