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
