Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
JBoss Portal developer's blog
Subscribe Now
Twitter Updates
Contributors
Tags
- portal
- portlet
- release
- dev
- jboss
- conference
- talk
- JSF
- identity
- community
- sso
- tutorial
- presentation
- bridge
- ldap
- rant
- seam
- GWT
- ajax
- contribution
- ui
- richfaces
- EPP
- QA
- bestpractices
- fun
- jsr286
- movie
- portletbridge
- EC2
- ajaxworld
- ant
- authorization
- book
- build
- demo
- eXo
- fud
- identity idm
- maven
- migration
- opends
- opensso
- performance scalability
- portal security
- portlet ide
- review
- roadmap
- security
- wsrp
- xacml
4 comments:
Oh man, I think you don't know how to use it !
See, affects version, fix version, you can plan for next release, and so on. Yes with Jira.
Actually I was meaning that it is not possible to resolve partially an issue for a release and let it unresolved for another release.
So if an issue has 2 fix versions, then the issue must be resolved for both versions at the same time. Which leads us to create duplicates of the same issue in order to achieve the partial resolving.
perhaps this is just a matter of semantics. If you have an outstanding bug, that is being resolved in one release, but not in a future one (yet) you should simply create a reference back. We've done a lot of research for various tracking tools, and to be honest, overall, JIRA has come out on top every time. I'd post this directly to their team to get their take on it.
don't misunderstand me, I like the tool very much. And I think it accelerates how we develop software (compared to the previous sourceforge bug tracker :-) ).
When I think more about it, they should decouple the concept of "issue" and the concept of "resolution". An issue should be only an issue and it should be possible to have several resolutions related to an issue.
Creating duplicates issues that link to an issue is a poor substitution to what I described above.
Post a Comment