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.ht... 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