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]

Reply via email to