Re: Can we stop continually moving Devtools JIRAs to the next release?
Eh, I actually find that moving unfixed versions to the next version is more helpful, but that is just me. --jason On Sep 26, 2008, at 2:22 AM, Donald Woods wrote: Right, and the point was that we're automatically carrying JIRAs from release to release (75 in GEP 2.2.0) when we know less than half will probably get fixed, if ever. When opened, we should leave them set to Fix Version = Unknown (Unscheduled) and only set the Fix field when someone is going to work on them. We've started cleaning up the usage of the Fix field in the Server (only 17 assigned to 2.1.4 and 86 to 2.2) so we should try and do the same in all our projects. -Donald Jason Dillon wrote: Well, really the "Fix for version" in JIRA isn't practically used to state that each and every issue has been fixed for that version... only if the issue is resolved and fix version set. The version release muck rolls over all unresolved issues to the next version so that folks can keep track of stuff that is still pending... its not a commitment to fixing them in that version. But that is just how JIRA works OOTB. --jason On Sep 26, 2008, at 1:55 AM, Joe Bohn wrote: I think the problem is in setting the fix version too soon on many of these JIRAs. For the 2.1.1 and 2.1.2 server releases I tried to avoid setting the fix version unless it was really a target for the release or we were ready to check-in a fix. Perhaps we can do the same for devtools. Joe Ted Kirby wrote: Yes, I think that is what I did. As part of the GEP release process, I Administered the GERONIMODEVTOOLS JIRA project to update the released and unreleased versions. I "managed" the 2.1.3 release, and clicked the Release link to release it. This, I think, resulted in all that email. Ted On Thu, Sep 25, 2008 at 1:48 PM, Jason Dillon <[EMAIL PROTECTED] > wrote: Hrm... odd, cause the default when marking a version as released in JIRA asks to move unresolved issues to the next version... --jason On Sep 26, 2008, at 12:39 AM, Donald Woods wrote: Can we stop the blanket moving of Devtools JIRAs from one release to the next? We should really only move unfixed JIRAs to 2.2.0 if we have intentions of fixing them for the 2.2.0 release. Continually moving any open JIRAs once GEP is released is generating way too many emails and is not the proper usage of the Fix Versions field in JIRA, which should be used to denote to the community that we're going to "try our best" to resolve the issue in the denoted release. -Donald
Re: Can we stop continually moving Devtools JIRAs to the next release?
Right, and the point was that we're automatically carrying JIRAs from release to release (75 in GEP 2.2.0) when we know less than half will probably get fixed, if ever. When opened, we should leave them set to Fix Version = Unknown (Unscheduled) and only set the Fix field when someone is going to work on them. We've started cleaning up the usage of the Fix field in the Server (only 17 assigned to 2.1.4 and 86 to 2.2) so we should try and do the same in all our projects. -Donald Jason Dillon wrote: Well, really the "Fix for version" in JIRA isn't practically used to state that each and every issue has been fixed for that version... only if the issue is resolved and fix version set. The version release muck rolls over all unresolved issues to the next version so that folks can keep track of stuff that is still pending... its not a commitment to fixing them in that version. But that is just how JIRA works OOTB. --jason On Sep 26, 2008, at 1:55 AM, Joe Bohn wrote: I think the problem is in setting the fix version too soon on many of these JIRAs. For the 2.1.1 and 2.1.2 server releases I tried to avoid setting the fix version unless it was really a target for the release or we were ready to check-in a fix. Perhaps we can do the same for devtools. Joe Ted Kirby wrote: Yes, I think that is what I did. As part of the GEP release process, I Administered the GERONIMODEVTOOLS JIRA project to update the released and unreleased versions. I "managed" the 2.1.3 release, and clicked the Release link to release it. This, I think, resulted in all that email. Ted On Thu, Sep 25, 2008 at 1:48 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: Hrm... odd, cause the default when marking a version as released in JIRA asks to move unresolved issues to the next version... --jason On Sep 26, 2008, at 12:39 AM, Donald Woods wrote: Can we stop the blanket moving of Devtools JIRAs from one release to the next? We should really only move unfixed JIRAs to 2.2.0 if we have intentions of fixing them for the 2.2.0 release. Continually moving any open JIRAs once GEP is released is generating way too many emails and is not the proper usage of the Fix Versions field in JIRA, which should be used to denote to the community that we're going to "try our best" to resolve the issue in the denoted release. -Donald
Re: Can we stop continually moving Devtools JIRAs to the next release?
Well, really the "Fix for version" in JIRA isn't practically used to state that each and every issue has been fixed for that version... only if the issue is resolved and fix version set. The version release muck rolls over all unresolved issues to the next version so that folks can keep track of stuff that is still pending... its not a commitment to fixing them in that version. But that is just how JIRA works OOTB. --jason On Sep 26, 2008, at 1:55 AM, Joe Bohn wrote: I think the problem is in setting the fix version too soon on many of these JIRAs. For the 2.1.1 and 2.1.2 server releases I tried to avoid setting the fix version unless it was really a target for the release or we were ready to check-in a fix. Perhaps we can do the same for devtools. Joe Ted Kirby wrote: Yes, I think that is what I did. As part of the GEP release process, I Administered the GERONIMODEVTOOLS JIRA project to update the released and unreleased versions. I "managed" the 2.1.3 release, and clicked the Release link to release it. This, I think, resulted in all that email. Ted On Thu, Sep 25, 2008 at 1:48 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: Hrm... odd, cause the default when marking a version as released in JIRA asks to move unresolved issues to the next version... --jason On Sep 26, 2008, at 12:39 AM, Donald Woods wrote: Can we stop the blanket moving of Devtools JIRAs from one release to the next? We should really only move unfixed JIRAs to 2.2.0 if we have intentions of fixing them for the 2.2.0 release. Continually moving any open JIRAs once GEP is released is generating way too many emails and is not the proper usage of the Fix Versions field in JIRA, which should be used to denote to the community that we're going to "try our best" to resolve the issue in the denoted release. -Donald
Re: Can we stop continually moving Devtools JIRAs to the next release?
I think the problem is in setting the fix version too soon on many of these JIRAs. For the 2.1.1 and 2.1.2 server releases I tried to avoid setting the fix version unless it was really a target for the release or we were ready to check-in a fix. Perhaps we can do the same for devtools. Joe Ted Kirby wrote: Yes, I think that is what I did. As part of the GEP release process, I Administered the GERONIMODEVTOOLS JIRA project to update the released and unreleased versions. I "managed" the 2.1.3 release, and clicked the Release link to release it. This, I think, resulted in all that email. Ted On Thu, Sep 25, 2008 at 1:48 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: Hrm... odd, cause the default when marking a version as released in JIRA asks to move unresolved issues to the next version... --jason On Sep 26, 2008, at 12:39 AM, Donald Woods wrote: Can we stop the blanket moving of Devtools JIRAs from one release to the next? We should really only move unfixed JIRAs to 2.2.0 if we have intentions of fixing them for the 2.2.0 release. Continually moving any open JIRAs once GEP is released is generating way too many emails and is not the proper usage of the Fix Versions field in JIRA, which should be used to denote to the community that we're going to "try our best" to resolve the issue in the denoted release. -Donald
Re: Can we stop continually moving Devtools JIRAs to the next release?
Yes, I think that is what I did. As part of the GEP release process, I Administered the GERONIMODEVTOOLS JIRA project to update the released and unreleased versions. I "managed" the 2.1.3 release, and clicked the Release link to release it. This, I think, resulted in all that email. Ted On Thu, Sep 25, 2008 at 1:48 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > Hrm... odd, cause the default when marking a version as released in JIRA > asks to move unresolved issues to the next version... > > --jason > > > On Sep 26, 2008, at 12:39 AM, Donald Woods wrote: > >> Can we stop the blanket moving of Devtools JIRAs from one release to the >> next? We should really only move unfixed JIRAs to 2.2.0 if we have >> intentions of fixing them for the 2.2.0 release. Continually moving any >> open JIRAs once GEP is released is generating way too many emails and is not >> the proper usage of the Fix Versions field in JIRA, which should be used to >> denote to the community that we're going to "try our best" to resolve the >> issue in the denoted release. >> >> >> -Donald >> >> > >
Re: Can we stop continually moving Devtools JIRAs to the next release?
Hrm... odd, cause the default when marking a version as released in JIRA asks to move unresolved issues to the next version... --jason On Sep 26, 2008, at 12:39 AM, Donald Woods wrote: Can we stop the blanket moving of Devtools JIRAs from one release to the next? We should really only move unfixed JIRAs to 2.2.0 if we have intentions of fixing them for the 2.2.0 release. Continually moving any open JIRAs once GEP is released is generating way too many emails and is not the proper usage of the Fix Versions field in JIRA, which should be used to denote to the community that we're going to "try our best" to resolve the issue in the denoted release. -Donald
Can we stop continually moving Devtools JIRAs to the next release?
Can we stop the blanket moving of Devtools JIRAs from one release to the next? We should really only move unfixed JIRAs to 2.2.0 if we have intentions of fixing them for the 2.2.0 release. Continually moving any open JIRAs once GEP is released is generating way too many emails and is not the proper usage of the Fix Versions field in JIRA, which should be used to denote to the community that we're going to "try our best" to resolve the issue in the denoted release. -Donald
