[boost] [#1497] Ruling needed on tracker usage

Subject: [boost] [#1497] Ruling needed on tracker usage
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-05-29 18:12:16

Dave is pressing to do something about this ticket:

>  Yes, please!  Beman, please read the head of that thread:
>  http://thread.gmane.org/gmane.comp.lib.boost.devel/167139
> 
>  IMO this is '''exceedingly''' important, and the only reason I'm not doing
>  it myself is that it seems to be the domain of the release managers.  It
>  will be an especially huge missed opportunity if we don't get this
>  straightened out before the bug sprint.  Oops!  That starts today!  We'd
>  better get moving.
> 
>  Again, if there's any way I can help, including writing the policy, please
>  let me know.  By the way, I'm not attached to eliminating "to be
>  determined," if that helps in any way to resolve this.

The concern of the thread mentioned was about milestones for 1.35.0. The 
same concern applies today, although the milestone numbers have changed.

 > [the milestone list]
> shows all the tickets that have been assigned to the 1.35.0 milestone.
> Does this list have any meaning?

It doesn't for me, and hasn't since we went to a schedule-driven release 
system a year and a half ago.

>  In other words, are we actually
> intending to address all of these problems for 1.35, and put off other
> tickets for 1.35.1 or 1.36.0?
> 
> IMO getting this list sorted out and handling the tickets one-by-one
> is the most productive way to get us from here to a successful release
> of 1.35.0.  That may mean a number of new tickets need to be added
> (probably at least one for each major failure we're seeing in
> http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.html
> and possibly others) and it will require part of the release team to
> triage the whole list of tickets assigned to 1.35.0 and make some
> decisions to put certain tickets off for later.

In an organization with paid developers and paid managers, it might be 
possible to look at the tickets, look at the people and other resources 
available, assign milestone priorities accordingly, and then use 
progress on clearing them as a metric to guide release activities.

But I'm at a loss for how we could use such milestones for Boost. So any 
ideas would be appreciated if folks think the milestones do have a place 
in Boost's process of getting releases out.

--Beman