[cmake-developers] ReactOS: Important filed bug reports went to backlog en masse

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Aug 13 15:37:30 EDT 2012


On 2012-08-13 06:54-0400 David Cole wrote:

> This was actually my exact intent (to re-involve the original
> reporters via the notification system, since nobody else has picked up
> on the bugs enough to assign them), and this was just step 1.
>
> The bug tracker's roadmap page and what bugs are actually assigned to
> active CMake developers are two of the most important pieces of
> information we can get from the bug tracker.
>
> Having a bunch of bugs in there that nobody has ever looked at is just
> as useless as allowing emails on the list to fall through the cracks
> without any responses.
>
> I intend to do the same thing with bugs that are actually assigned to
> developers that have not been updated in the last 3 or 4 months. (If
> it hasn't been updated, then it's not really "active"...) If you care
> about a bug that's assigned to you, and want to get it fixed in CMake
> 2.8.10, please update it by adding a note by setting the Target
> Version field and putting it on the roadmap page.
>
> The ones that people really care about will be brought back. If nobody
> cares about an issue, then it's not really an issue. The bug tracker
> is an imperfect measurement of "care", but it's one of the closest
> proxies that we have.
>
>
> Thanks for your comments,

My comment is this is a really touchy political issue.

To be a devil's advocate, backlogging is generally a slap in the face
to those of us who have made an effort to present a careful,
well-documented bug report which often includes a patch that fixes the
issue.  My impression is a lot of such high-quality bug reports are
still ignored because of lack of resources to even make decisions on
whether the proposed fix is acceptable or not, and this lack of
resources to do decision making has now been formalized with the
backlogging idea.  Why should we try to make high-quality bug reports
for CMake if we have to periodically do additional and completely
non-productive work to justify not throwing our prior good effort on
the trash heap (i.e., backlog)?

Note, these are devil's advocate points, and I do personally
understand the necessity of a measure like this to keep your limited
bug-fixing resources focussed on issues where the bug reporter really
cares about the outcome, and also to achieve higher signal-to-noise
ratio in the bugtracker for issues that are not backlogged. But I
would make sure that the period of time before a bug is backlogged is
generous (at least a year), and I would advertise that period of time
up front on the bugtracker as part of a notice that carefully
justifies the measure and which also warns the would-be bug reporter
that it is normally a long-term commitment to keep his bug report out
of the trash heap if his bug report does not attract the attention of
a CMake developer (regardless of whether they are salaried by Kitware
or volunteer).

Also, this whole issue is a clear sign that CMake does not have enough
_organized_ bug report evaluation resources at the moment (for example,
to simply test and evaluate all patches that appear on the bug
tracker).  My impression from all the traffic on this list is the
volunteer development community for CMake is growing rapidly, but
perhaps you (David) might be able to harness some of that volunteer
energy by periodically giving a report on the numbers of unresolved
bugs on the bugtracker and asking for volunteers to help with
evaluation of those.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



More information about the cmake-developers mailing list