Re: [groff] Maintainer out of bounds

[Ingo Schwarze]

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