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.
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.
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. 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.
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". And I prefer to define it as "the set of issues that are part of the 1.35.0 release". 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. Just make sure to describe the milestone (in trac) to make it clear that it's a prospective determination. 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? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo