Re: [boost] Report # 29 (aka 1.45 blockers) is too narrow

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