Re: Bug maintenance
On 08/05/16 23:13, Oleg Endo wrote: There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. That's exactly what prompted me to ask. There's such a vast number of them, it's hard to believe that 9 year old bugs are still of interest. Sometimes there is. Before randomly closing any bugs because they are too old, one should@least have a look@them and see if they're still an issue etc. Often things would've been fixed along the way, but not all of them. There are some 10-years old bugs that have a very clear description of what needs to be done to fix them, it is just that no one has had time to do it yet. Others don't have a clear fix, but there is a lot of info about things tried but failed. Losing all that info would be bad. My humble opinion is that going through the list from old to new is not the most useful or efficient way to contribute to GCC (if it is the only way you want to contribute, then please go ahead, it is still useful). Old bugs do not hurt anyone except perhaps when searching for duplicates. In that case, it may be worth spending a few minutes checking if it is fixed already, ask the submitter for more info, or confirm it if UNCONFIRMED and updating the description so one can see clearly that it is not a duplicate. Triaging old bugs (except for fixing them) is not the most useful: users may have simply forgotten all about it or not be able to reproduce it anymore or moved on and not care... On the other hand, it is rather more useful to start with recent bugs, which are more likely to be relevant, and confirm them, ask for more info, find oldest duplicate with more info, or classify them under various meta-bugs. Rather than seeing Bugzilla as a TODO list for devs, it is rather more precise to see it as a knowledge database about bugs. Cheers, Manuel.
Re: Bug maintenance
On 05/08/2016 04:13 PM, Oleg Endo wrote: Sometimes there is. Before randomly closing any bugs because they are too old, one should at least have a look at them and see if they're still an issue etc. Often things would've been fixed along the way, but not all of them. When this is the case I do try to git bisect the issue so that I can confidently say the issue is fixed rather than just latent. Of course that dramatically increases the amount of time necessary to squash out any issue that seems to be working correctly on the trunk. jeff
Re: Bug maintenance
On 05/08/2016 04:03 PM, David Wohlferd wrote: On 4/28/2016 9:41 AM, Martin Sebor wrote: On 04/28/2016 01:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. That's exactly what prompted me to ask. There's such a vast number of them, it's hard to believe that 9 year old bugs are still of interest. I consistently fix a few of these for every release, as do other developers. They're all still of interest, though regressions certainly get the most attention. I do think the backlog is too large and needs a good cleanout and will encourage anyone with an interest to do whatever they can to flush out old bugs. jeff
Re: Bug maintenance
On Sun, 2016-05-08 at 15:03 -0700, David Wohlferd wrote: > On 4/28/2016 9:41 AM, Martin Sebor wrote: > > On 04/28/2016 01:35 AM, David Wohlferd wrote: > > > As part of the work I've done on inline asm, I've been looking > > > thru the > > > bugs for it. There appear to be a number that have been fixed or > > > overtaken by events over the years, but the bug is still open. > > > > > > Is closing some of these old bugs of any value? > > > > > > If so, how do I pursue this? > > > > There are nearly 10,000 still unresolved bugs in Bugzilla, almost > > half of which are New, and a third Unconfirmed, so I'm sure any > > effort to help reduce the number is of value and appreciated. > > That's exactly what prompted me to ask. There's such a vast number > of them, it's hard to believe that 9 year old bugs are still of > interest. Sometimes there is. Before randomly closing any bugs because they are too old, one should at least have a look at them and see if they're still an issue etc. Often things would've been fixed along the way, but not all of them. Cheers, Oleg
Re: Bug maintenance
On 4/28/2016 12:23 PM, Andrew Pinski wrote: On Thu, Apr 28, 2016 at 12:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? Yes it is. In fact this is how I got my start into GCC. If so, how do I pursue this? If you go through the bug reports and have a low rate of false positives, I (and others) can get you permission to change the bug reports (I started out with a bug report only account too). I'll do my best. But it's not always clear what might trigger a debate. I swear to you, I never expected 24414 to blow up the way it did. dw
Re: Bug maintenance
On 4/28/2016 9:41 AM, Martin Sebor wrote: On 04/28/2016 01:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. That's exactly what prompted me to ask. There's such a vast number of them, it's hard to believe that 9 year old bugs are still of interest. I can share with you my own approach to dealing with them (others might have better suggestions). In cases where the commit that fixed a bug is known, I mention it in the comment closing the bug. I also try to indicate the version in which the bug was fixed (if I can determine it using the limited number of versions I have built). Otherwise, when a test doesn't already exist (finding out whether or not one does can be tedious), I add one before closing the bug will help avoid a regression. I'll see what I can do. dw
Re: Bug maintenance
On 4/28/2016 2:01 AM, Richard Biener wrote: On Thu, Apr 28, 2016 at 9:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? Yes, definitely. If so, how do I pursue this? I suppose adding a final comment to them will work, people (like me) watching gcc-bugs can then do the actual closing. Perfect. That gives the OP a chance to respond as well. Look for my updates to 30527, 39440 & 43319. dw
Re: Bug maintenance
On Thu, Apr 28, 2016 at 12:35 AM, David Wohlferd wrote: > As part of the work I've done on inline asm, I've been looking thru the bugs > for it. There appear to be a number that have been fixed or overtaken by > events over the years, but the bug is still open. > > Is closing some of these old bugs of any value? Yes it is. In fact this is how I got my start into GCC. > > If so, how do I pursue this? If you go through the bug reports and have a low rate of false positives, I (and others) can get you permission to change the bug reports (I started out with a bug report only account too). Thanks, Andrew Pinski > > dw >
Re: Bug maintenance
On 04/28/2016 01:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. I can share with you my own approach to dealing with them (others might have better suggestions). In cases where the commit that fixed a bug is known, I mention it in the comment closing the bug. I also try to indicate the version in which the bug was fixed (if I can determine it using the limited number of versions I have built). Otherwise, when a test doesn't already exist (finding out whether or not one does can be tedious), I add one before closing the bug will help avoid a regression. Martin
Re: Bug maintenance
On Thu, Apr 28, 2016 at 9:35 AM, David Wohlferd wrote: > As part of the work I've done on inline asm, I've been looking thru the bugs > for it. There appear to be a number that have been fixed or overtaken by > events over the years, but the bug is still open. > > Is closing some of these old bugs of any value? Yes, definitely. > If so, how do I pursue this? I suppose adding a final comment to them will work, people (like me) watching gcc-bugs can then do the actual closing. Richard. > dw >
Bug maintenance
As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? dw
