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

David Cole david.cole at kitware.com
Mon Aug 13 17:23:32 EDT 2012


On Mon, Aug 13, 2012 at 3:37 PM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> 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
> __________________________


Thanks for your comments, Alan. Your input is always much appreciated
and valuable to the whole CMake community.

I realize that this is a touchy subject, and tried very hard to word
my messages that went along with this action to make it very clear
that putting a bug into the 'backlog' is not in the least bit
permanent. It literally takes just a second to flip a bug back to
'assigned' for those bugs that are deemed 'must fix'. The 'backlog' is
just a bucket (of *open issues* by the way, not closed, and certainly
not forgotten) that helps us to focus on the ones that are *not* in
it.

I am certainly not slapping anyone in the face, or questioning the
value of anyone else's time. I do apologize to those of you that felt
that way.

It's a difficult job to coordinate and analyze more than 1,200 open
issues. I want us to get to the point where we have a usefully small
set of issues that the CMake developers are focusing on, and yet keep
the rest around until they may be sufficiently addressed.

Once we get into a state such as that, and people realize that going
to the backlog is not a permanent state of affairs, it won't be quite
so dramatic as what I've done over the past few days.


Thanks,
David



More information about the cmake-developers mailing list