on Thu Nov 08 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Mon Nov 05 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
That means establishing a 1.36.0 milestone There's no need to create such a milestone. I created the "To Be Determined" milestone.
Why is putting tickets in "to be determined" better than assigning them to 1.36.0 until such time as we decide to do something else with them? I don't like limbo.
How is "to be determined" any more limbo than a "1.36.0"? Unless you are guaranteeing that they will be addressed in the "1.36.0" release there's nothing informative in adding them to such a milestone IMO.
Assuming we use the system with any discipline, you are guaranteeing someone will have to look at them and make an explicit decision on their fate, at least w.r.t. 1.36.0, before it is released. "To be determined" tickets can be dealt with or ignored without any imperative deadline.
Which means that in addition to looking at the tickets currently in the 1.35.0 milestone we need to look through the ones in "To Be Determined" to see if any apply for this release. But ideally I would rather see the bug handling to occur entirely outside the 1.35.0 milestone
What does that mean?
I guess what I meant was that if one wants the "1.35.0" milestone to reflect the state of the release then it should include the issues addressed in the release branch. As opposed to reflect the issues addressed in the trunk.
IMO given the current release procedure, the right way to deal with that is to have a ticket state called "fixed in trunk" and another called "merged to release branch." I think that requires the ticket workflow feature, which means a Trac upgrade. Doug has said OSL is willing to do that if necessary.
No bugs should be labelled as "must be fixed for the release of 1.35?"
If there are such issues then yes they can be part of the milestone.
How will we track our progress towards 1.35 releasability?
As we agreed before... A release happens on the day the release is due and the release branch is clear.
So Trac is completely out of the loop as a tool for managing our progress? Seems like a collosal missed opportunity to me.
But since the point of the new procedures is to revert any breaking changes done to the release branch under most circumstances there should be no unresolved issues in the release. Only postponed issues.
since all the bugs should be getting fixed in the trunk, not the release.
I don't understand what connection the area of the repository has with the milestone.
I guess that's where we disagree. I see a connection as the 1.35.0 milestone defining what the release branch has in it.
Ticket workflow is the answer to that.
Hence as a gross approximation we would move all the 1.35.0 tickets to the "to be determined" milestone. And when a library is placed in the branch we can move the resolved tickets only to 1.35.0.
You're suggesting having all open tickets in "To be determined," and only assinging milestones after they're closed? That doesn't seem like a very good use of the technology.
Perhaps. But this is sounding to me as just a semantic disagreement. You want to define the 1.35.0 milestone as the "prospective set of issues that may be part of the 1.35.0 release".
No, I define it as the issues that we're currently declaring need to be dealt with before 1.35.0 can be released. That's the open issues. Which milestone closed issues are assigned to matters little.
And I prefer to define it as "the set of issues that are part of the 1.35.0 release".
That's a really odd way to approach issue tracking. You'll note that the vast majority of reports don't show closed tickets. That means most people are looking at the issues that are currently unresolved. Taking a milestone assignment off the table as a way of sorting and filtering open issues and relegating it to use with closed issues sacrifices a lot of expressivity and potentially useful information.
I don't actually care which definition one picks, and if the first one is a better use of milestones then the latter is fine.
IMO the first one is a better use of milestones and the latter is anything but fine.
Just make sure to describe the milestone (in trac) to make it clear that it's a prospective determination.
I'd lay dollars to donuts that you're an outlier in this: I can't believe that most experienced developers would be confused about the meaning of assinging an open ticket to a milestone.
But I would still like to have some representation of what issues are address that are already part of the release branch. So maybe we need a new milestone just for that?
Ticket workflow. :) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com