On 1:59 PM, Eric Niebler wrote:
On 10/25/2010 7:01 PM, Jim Bell wrote:
On 1:59 PM, Eric Niebler wrote:
On 10/25/2010 6:41 AM, Jim Bell wrote:
So all agree that the 1.45 blockers report needs to be changed, at least to remove the milesone. No, I object. That list represents bugs that the release managers have deemed important. I'm not convinced of that, particularly in light of the milestone filter being as narrow as it is.
I don't see evidence that anyone has reviewed most of the showstoppers, particularly those missed by the current filter. You're right, it's probably the case that nobody has reviewed these.
Further, this suggests that release managers deliberately left showstopping tickets open for previous revisions. Really? Just 'cause someone says it's a showstopper doesn't mean it is.
Demoting a ticket's severity from showstopper would constitute evidence that it's been reviewed, but the fact that all these exist suggests that they haven't. No, the fact that the bugs haven't been "accepted" is evidence that they haven't been reviewed.
Thanks for the clarifications. I wasn't aware of "accepted". But I don't see any way of querying for 'accepted' (from custom query). Can one query on 'accepted'? Is it done on a regular basis? (I do see 'accept' under Modify Ticket/Action for existing tickets.)
A query for "accepted showstoppers" turns up exactly one that our filter missed:
https://svn.boost.org/trac/boost/ticket/3550
I'll reset its milestone so that our filter picks it up. (Right now I can't because the Trac keeps telling me the database is locked. Why does our Trac consistently perform so poorly? Anyone?)
My perception of trac is that it runs slow, but that might be from boost alone. Anyone know of a trac site that performs well?
Of the five tickets marked showstopper for 1.43 (3892, 3967, 4065, 4097, 4266), none show any change to their severity, so they were set by their originator (a "random boost user"), neither closed nor modified by a release manager, and 1.43 was released. Any objective observer would conclude that they simply got missed. True. And several of those have not been accepted. Troubling. Not everybody is playing by the same rules. :-(
The bugs that random boost users deem important is less interesting. Agreed.
Would it be nice to go through all the bugs and make sure they're categorized correctly? You bet. Would I hold up 1.45 for it? Nope. We seem to agree that a release manager (or a library's author?) should go through at least the showstoppers and demote their severity. (Yes?) It's the job of a library maintainer to review bugs, *accept the ones that are legit* and set the priority and milestone if necessary. Until they're accepted we can only assume that they've never been looked at.
We need to give boost users some confidence that their bug report hasn't been completely neglected.
Review managers aren't in the best position to determine whether a bug is really a showstopper. ... At some point we have to say screw it and move ahead with the release (with an appropriate BIG warning in the release notes).
The expectation is that releases work. A big warning in the release notes might not be big enough. A big warning in the Getting Started Guide might do it. But, again, that's only if we know what doesn't work. Telling people to go the more intimidating route--doing their own release check-out--would be better than pushing out a release, IMHO. (But I think that would scare away a bunch of people.)
The best we can do is prod some library maintainer and ask for clarification. We should probably be more proactive about that.
And what if an accepted showstopper isn't getting fixed because the maintainer is busy? ...
I think we need a new batch of volunteers to help. I don't want library authors to think they're taking on a ball and chain for writing a library: an endless series of tickets spanning the gamut from user error to legit show-stoppers. New thread...