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

From: David Abrahams (dave_at_[hidden])
Date: 2007-11-08 13:42:29

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