Report # 29 (aka 1.45 blockers) is too narrow
I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months. A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that. I think they all need review.
Jim Bell wrote:
I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months.
A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that.
Or the ticket's originator may have used "showstopper" just because he overestimated the importance of the bug. Therefore, "showstopper" severity does not necessary mean anything.
I think they all need review.
And -- who exactly do you suggest review them -- given that per above, you actually have to review every single open bug, not just bugs with specific severity. - Volodya
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, October 24, 2010 7:40 PM Subject: Re: [boost] Report # 29 (aka 1.45 blockers) is too narrow
Jim Bell wrote:
I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months.
A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that.
Or the ticket's originator may have used "showstopper" just because he overestimated the importance of the bug. Therefore, "showstopper" severity does not necessary mean anything.
It is up to the maintainer or someone else to change the severity if not correct.
I think they all need review.
And -- who exactly do you suggest review them -- given that per above, you actually have to review every single open bug, not just bugs with specific severity.
We need to review all of them of course and by respect to the reporter, we should start by more critical. For the more critical we can start by the newests. I agree that a new release of Boost should not be done as far as there are regressions or showstoppers. Best, Vicente
vicente.botet wrote:
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, October 24, 2010 7:40 PM Subject: Re: [boost] Report # 29 (aka 1.45 blockers) is too narrow
Jim Bell wrote:
I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months.
A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that.
Or the ticket's originator may have used "showstopper" just because he overestimated the importance of the bug. Therefore, "showstopper" severity does not necessary mean anything.
It is up to the maintainer or someone else to change the severity if not correct.
I think they all need review.
And -- who exactly do you suggest review them -- given that per above, you actually have to review every single open bug, not just bugs with specific severity.
We need to review all of them of course and by respect to the reporter, we should start by more critical. For the more critical we can start by the newests.
Ok, would you please review them, in the suggested order? I'm merely pointing out that Stowstopper+1.45 is a list of issues that were explicitly designated as potential showstoppers for 1.45, and is meant to make it less likely to have 1.45 released with such showstoppers unresolved. While it's good to review other issues from time to time, that goal is entirely separate from the goal of not forgetting to resolve the issues that we think should be really resolved for 1.45. - Volodya
On 1:59 PM, Vladimir Prus wrote:
vicente.botet wrote:
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, October 24, 2010 7:40 PM Subject: Re: [boost] Report # 29 (aka 1.45 blockers) is too narrow
Jim Bell wrote:
I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months.
A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that. Or the ticket's originator may have used "showstopper" just because he overestimated the importance of the bug. Therefore, "showstopper" severity does not necessary mean anything.
I appreciate not wanting to be at the mercy of any yahoo with a barrage of new tickets. (Like me!) But if we're all in this together (and we are), then existing tickets need to be reviewed more carefully than they are at present.
It is up to the maintainer or someone else to change the severity if not correct.
But it's up to the one making a boost-1.45 release to make sure all showstopper and regression tickets are resolved, holding up the release as necessary.
I think they all need review. And -- who exactly do you suggest review them -- given that per above, you actually have to review every single open bug, not just bugs with specific severity. We need to review all of them of course and by respect to the reporter, we should start by more critical. For the more critical we can start by the newests. Ok, would you please review them, in the suggested order? I'm merely pointing out that Stowstopper+1.45 is a list of issues that were explicitly designated as potential showstoppers for 1.45, and is meant to make it less likely to have 1.45 released with such showstoppers unresolved.
While it's good to review other issues from time to time, that goal is entirely separate from the goal of not forgetting to resolve the issues that we think should be really resolved for 1.45.
So all agree that the 1.45 blockers report needs to be changed, at least to remove the milesone. What about adding 'regression' to it as well? That field of dandelions on the test matrix reduces confidence in all of boost. And previously filtered showstoppers need to be at least re-categorized, if not addressed.
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. 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. -- Eric Niebler BoostPro Computing http://www.boostpro.com
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. Further, this suggests that release managers deliberately left showstopping tickets open for previous revisions. Really? 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. 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.
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?) But that still lets random boost users deem the importance of the non-showstoppers, which doesn't seem right either. Unless they get reviewed. 1.44 has problems, and I'm convinced that the quality of 1.45 is more important than it's timely release.
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. 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?)
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. Review managers aren't in the best position to determine whether a bug is really a showstopper. 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? At some point we have to say screw it and move ahead with the release (with an appropriate BIG warning in the release notes).
But that still lets random boost users deem the importance of the non-showstoppers, which doesn't seem right either. Unless they get reviewed.
1.44 has problems, and I'm convinced that the quality of 1.45 is more important than it's timely release.
Agreed. -- Eric Niebler BoostPro Computing http://www.boostpro.com
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...
On 10/26/2010 07:35 AM, Jim Bell wrote:
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?
My personal experience is that with an adequately resourced machine and a properly configured trac setup that it will run plenty fast. Take a look at trac.edgewall.org which is running on trac. While there ... you can search for "slow" and see all kinds of reasons for the server to run sluggish. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Oct 26, 2010, at 7:35 AM, Jim Bell wrote:
On 1:59 PM, Eric Niebler wrote:
On 10/25/2010 7:01 PM, Jim Bell wrote:
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".
For posterity, here's a link: <https://svn.boost.org/trac/boost/wiki/TicketWorkflow> Suggestions/updates welcome. -- Marshall
On 10/26/2010 7:35 AM, Jim Bell wrote:
On 1:59 PM, Eric Niebler wrote:
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.
We need another sprint, and we need to call out bug triage explicitly as a service we'd like people to volunteer for. Having such volunteers on an ongoing basis would be very, very nice. As jobs go, it's particularly inglorious, but I think you've identified a real need.
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.
That is the reality of being a boost library author. As the author and active maintainer of 4 boost libraries, I know the pain. But if you want people to actually USE your code, you have to be ready to deal with complaints. If you can't commit to fixing bugs, don't submit a library to boost. That said, if an author can convince some volunteers to help out with this sort of stuff, then all the better. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
No, I object. That list represents bugs that the release managers have deemed important. The bugs that random boost users deem important is less interesting.
Nice to know how you really view the user community. Thanks. Feelings mutual.
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.
And if you put it off now, you'll put it off again. When did a subproject last get ejected from Boost because its not actively maintained and tickets get left? And how much would that tarnish the reputation you'd like? Do you think postgresql would release with the same set of issues?
James Mansion wrote:
Eric Niebler wrote: No, I object. That list represents bugs that the release managers have deemed important. The bugs that random boost users deem important is less interesting.
Nice to know how you really view the user community. Thanks. Feelings mutual.
The job of the release manager is defining what's "important" to the release. That's their job. Just because some bug is critical in my world doesn't mean that the release manager should hold up the release. It's not personal. It's their job.
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.
And if you put it off now, you'll put it off again. When did a subproject last get ejected from Boost because its not actively maintained and tickets get left?
Maybe it will get put off again, maybe it won't. The release manager's job is to make the call as to whether or not to put out the release. It's not their job to fix all the bugs. That's the boost community's job. The subject of dropping unmaintained projects is a valid one, and has been discussed here before. I have a great appreciation for all of the boost contributors, and for the efforts of the folks at boostpro in particular. We all benefit greatly from their hard work. Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Monday, October 25, 2010 8:44 AM Subject: Re: [boost] Report # 29 (aka 1.45 blockers) is too narrow
vicente.botet wrote:
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, October 24, 2010 7:40 PM Subject: Re: [boost] Report # 29 (aka 1.45 blockers) is too narrow
Jim Bell wrote:
I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months.
A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that.
Or the ticket's originator may have used "showstopper" just because he overestimated the importance of the bug. Therefore, "showstopper" severity does not necessary mean anything.
It is up to the maintainer or someone else to change the severity if not correct.
I think they all need review.
And -- who exactly do you suggest review them -- given that per above, you actually have to review every single open bug, not just bugs with specific severity.
We need to review all of them of course and by respect to the reporter, we should start by more critical. For the more critical we can start by the newests.
Ok, would you please review them, in the suggested order?
I'd try it.
I'm merely pointing out that Stowstopper+1.45 is a list of issues that were explicitly designated as potential showstoppers for 1.45, and is meant to make it less likely to have 1.45 released with such showstoppers unresolved.
I agree and I will add that the Stowstopper+1.45 should be limited to errors found on the release branch.
While it's good to review other issues from time to time, that goal is entirely separate from the goal of not forgetting to resolve the issues that we think should be really resolved for 1.45.
I also agree :) Best, Vicente
----- Original Message ----- From: "Jim Bell" <Jim@JC-Bell.com> To: <boost@lists.boost.org> Sent: Sunday, October 24, 2010 7:32 PM Subject: [boost] Report # 29 (aka 1.45 blockers) is too narrow
I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months.
A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that.
I think they all need review.
the initial query didn't filer the Milestone. Who changed the query title and contents? Best, Vicente
participants (8)
-
Eric Niebler -
James Mansion -
Jim Bell -
Marshall Clow -
Michael Caisse -
Nelson, Erik - 2 -
vicente.botet -
Vladimir Prus