Subject: Re: [boost] Report # 29 (aka 1.45 blockers) is too narrow
From: Jim Bell (Jim_at_[hidden])
Date: 2010-10-26 10:35:22
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:
> 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.
>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk