Hi Ralph, Ralph Corderoy wrote on Thu, Sep 20, 2018 at 03:41:30PM +0100: > Werner Lemberg wrote:
>> Ingo, please mark such reports as `wontfix' in the future if you think >> that nothing should be done. > I think Ingo is wrong. Like you, I think that all of groff's warnings > for source groff ships should be fixed as otherwise they're noise that > cheapens all warnings and means new ones, either due to an improvement > or regression, might be missed. But is Ingo the only `gardener' of > http://savannah.gnu.org/bugs/?group=groff ? I think every developer is highly welcome to do triage, and occasionally others do indeed commit fixes for valid bug reports or close invalid or irrelevant ones. But as a matter of fact, few enough of the groff developers do that, and do so rarely enough, that as a group, we fail to keep up with triage. Currently, there are * 114 open bug reports * 66 open bug reports with status "None". That is the majority of open bug reports. * 85 open bug reports assigned to "None". * 57 open bug reports with category "None". Again, that is the majority of open bug reports. * 25 open bug reports with item group "None". Ideally, the status should be set to "Confirmed", "Need Info", or to the appropriate one of the various invalid markers within, say, a few weeks (or at worst months) of submission, and so should the category and item group. I occasionally try to help with that even though groff, for me personally, is a side project, even if a side project that i care about. But many bug tracker entries are so dubious that in the past, i did not dare to make a decision what the status and item group should be. In many cases, i added short comments proposing what to do with the items. I relatively rarely received feedback on such comments, even though every such comment causes a mail to be sent out to the bugs-groff list. In cases that seem clear to me, i try to be bold and just make a decision. In cases where i have doubts what others might think, i add a comment. I think in such cases, two developers agreeing would be sufficient to make a decision and set the attributes - if others would disagree, they could always speak up: decisions in the bug tracker can always be corrected. > If not, I think Ingo should ignore these kind that he doesn't agree > with and allow someone else to tend to them. They're not wishlist, > nor are they wontfix. If you look at the 66 open bug reports with status "None", 40 of them were submitted by Bjarni, and 39 out of the 46 ones submitted in 2017 and 2018. All of those submitted by Bjarni are of very low importance. That is a problem because it drowns the reports that really matter in noise. The argument has been brought up that you can use criteria in the search form to filter out what really matters. But unfortunately, that is kind of a straw man argument as long as people are so overworked that the attributes do not actually get set. Also, the search function in the Savannah bug tracker is quite weak, and besides, filtering by summary or submitter is only available to developers, not to the public. So it does matter to keep the bugtracker clean, and the number of issues low. >> He gave an explanation in https://savannah.gnu.org/bugs/?54475: >> >> As a rule, reporting a compiler warning in the bugtracker is >> detrimental unless there is reason to believe that there is an >> actual bug. > Running Arch Linux, I often have a gcc or clang that's later than all > the main developers of a project. Thus I'm the first to raise a bug > with new compilation warnings and I can't recall an occasion when it > wasn't happily received. I find that very strange. I have often seen bogus compiler warnings even from old compilers, and new compilers tend to get more and more aggressive warning about more and more nits. So most definitely, false positives do exist in very significant numbers, and reporting them is certainly annoying. I guess you followed the second half of my rule of thumb and only reported warnings where the code could actually be improved - so people were maybe happy for that reason. Anyway, i would highly welcome everybody having technician and/or manager privileges on the bugtracker to occasionally browse bug reports as time permits, set missing attributes that appear as obvious and likely uncontroversial, add short comments with proposals for attributes where in doubt, and set the attributes on items already having such comments that they agree with. Such that we actually get triage done. Currently, we are falling behind, and it's getting worse lately. The main reason why the usefulness of bugtrackers tends to degrade over time is clutter. Yours, Ingo
