Re: [boost] [1.35.0] Tickets, Milestone, Testing

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-11-08 11:01:54

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