[#1497] Ruling needed on tracker usage
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
2009/5/29 Beman Dawes <bdawes@acm.org>:
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.
Yep, automatically assigning all new tickets to the next milestone is unrealistic. So maybe new tickets could be set to 'to be determined' and then maintainers could update the milestone when they accept a ticket. And then, hopefully, the only tickets with that milestone will be ones that somebody intended to fix in that release. It might also be worth checking show stoppers, even if it's only to demote them. Hopefully that system wouldn't require too much effort. Daniel
on Fri May 29 2009, Beman Dawes <bdawes-AT-acm.org> wrote:
[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.
Milestones could be assigned by release managers and library maintainers to critical steps that need to be handled for each release. I believe we're also going to need to have some actions such as "modularization" that apply to Boost as a whole, and should be targeted at a particular release. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (3)
-
Beman Dawes -
Daniel James -
David Abrahams