I'll mention how we do it in case it sparks inspiration...
We use Jira to manage issues for several software configurations and
packages. Because of our odd agile process, we never really know when
we're going to cut a release (which is sort of similar to you guys but
we're more customer driven in this case).
To manage this, we always have -Next and -Future versions in Jira. So
for a Foo package, we'd have Foo-Next and Foo-Future. When we know when
our next release will be, we change the name of Foo-Next to Foo-x.y.z or
whatever and make a new Foo-Next. We then move any Foo-x.y.z issues out
of Foo-Next if we don't think they'll make it in. We do this because it
forces us to readdress the pending issues with each release and close
them or move the to -Future if they somehow fall out of pending status.
From the submitter's perspective, they also get an e-mail notification
that their issue won't be making it into the next release.
One could just as easily create a new Foo-x.y.z and move issues from
Foo-Next into it. In our environment, we prefer to have to cycle
through the issues each time since we're customer driven and not
development driven.
This allows us to track what we feel are the three major categories of
issues: 1) issues scheduled for a specific release, 2) issues pending
scheduling, 3) future issues that may need more research or otherwise be
more appropriate for some future major version bump/rearchitecture
before scheduling is feasible.
For what it's worth.
-Paul
Ted Husted wrote:
On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote:
Step 2:
- Move closed tickets included in soon-to-be-released projects to their
milestone.
- Wade through TBD tickets and assign to milestones
While I like Martin's idea of only putting tickets to milestones when someone
commits to resolving them, I'm afraid it would distort the roadmap by giving the
wrong impression that we are always close to a release. Perhaps we could start
using the "Assigned" field more often to mark which ones have been taken up and
which are just hanging.
I'd be more concerned about giving people the wrong impression that
someone is going to resolve the ticket before the next release.
IMHO, if a committer assigns a ticket to a milestone, then that
committer is saying he or she is going to make it so.
:) Otherwise, we have a situation where someone who is not planning to
do the work is making the decision :)
And, if the bugs are resolved, we *should* always be close to a
release. In 1.0 to 1.1 era, we were always saying "let's get this one
last feature in before we release". I don't think that worked well for
us. If we start setting tickets to milestones when there is not a
volunteer ready, willing, and able to work on the ticket, we're
falling back into the old pattern that says a release has to be big to
be worthwhile.
Hey, I'd be in favor of releasing after any ticket is resolved. Fix a
bug, add a feature, roll a release -- works for me!
If we end up with milestones like 2.3.52, then so be it. MySQL does
that, and I never blinked.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]