An update and clarification of one of my simple facts: :-)<div><br></div><div>  - There are presently 1,207 "open issues" in the CMake bug tracker,</div><div><br></div><div>  but "open" in this number also includes already "resolved" bugs, of which there are presently 193.</div>
<div><br></div><div>So, really, there are 1,014 open issues that require work to resolve them...</div><div><br></div><div><br></div><div>Thx,</div><div>David</div><div><br><br><div class="gmail_quote">On Mon, Aug 13, 2012 at 5:27 PM, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here are some simple facts:<br>
<br>
  - There are presently 1,204 open issues in the CMake bug tracker.<br>
<br>
  - We averaged 111 days per release from CMake 2.8.1 to CMake 2.8.9.<br>
<br>
  - Each release contained an average of 79 bug fixes from 2.8.3 to 2.8.9.<br>
<br>
Hence...... I have a strong desire to focus in on approximately 79<br>
bugs for the CMake 2.8.10 release, and shelve the remaining 1,125 bugs<br>
for future consideration.<br>
<br>
What we're doing here with the 'backlog' category is simply a focusing effort.<br>
<br>
<br>
Thank you,<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Aug 13, 2012 at 5:23 PM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
> On Mon, Aug 13, 2012 at 3:37 PM, Alan W. Irwin<br>
> <<a href="mailto:irwin@beluga.phys.uvic.ca">irwin@beluga.phys.uvic.ca</a>> wrote:<br>
>> On 2012-08-13 06:54-0400 David Cole wrote:<br>
>><br>
>>> This was actually my exact intent (to re-involve the original<br>
>>> reporters via the notification system, since nobody else has picked up<br>
>>> on the bugs enough to assign them), and this was just step 1.<br>
>>><br>
>>> The bug tracker's roadmap page and what bugs are actually assigned to<br>
>>> active CMake developers are two of the most important pieces of<br>
>>> information we can get from the bug tracker.<br>
>>><br>
>>> Having a bunch of bugs in there that nobody has ever looked at is just<br>
>>> as useless as allowing emails on the list to fall through the cracks<br>
>>> without any responses.<br>
>>><br>
>>> I intend to do the same thing with bugs that are actually assigned to<br>
>>> developers that have not been updated in the last 3 or 4 months. (If<br>
>>> it hasn't been updated, then it's not really "active"...) If you care<br>
>>> about a bug that's assigned to you, and want to get it fixed in CMake<br>
>>> 2.8.10, please update it by adding a note by setting the Target<br>
>>> Version field and putting it on the roadmap page.<br>
>>><br>
>>> The ones that people really care about will be brought back. If nobody<br>
>>> cares about an issue, then it's not really an issue. The bug tracker<br>
>>> is an imperfect measurement of "care", but it's one of the closest<br>
>>> proxies that we have.<br>
>>><br>
>>><br>
>>> Thanks for your comments,<br>
>><br>
>><br>
>> My comment is this is a really touchy political issue.<br>
>><br>
>> To be a devil's advocate, backlogging is generally a slap in the face<br>
>> to those of us who have made an effort to present a careful,<br>
>> well-documented bug report which often includes a patch that fixes the<br>
>> issue.  My impression is a lot of such high-quality bug reports are<br>
>> still ignored because of lack of resources to even make decisions on<br>
>> whether the proposed fix is acceptable or not, and this lack of<br>
>> resources to do decision making has now been formalized with the<br>
>> backlogging idea.  Why should we try to make high-quality bug reports<br>
>> for CMake if we have to periodically do additional and completely<br>
>> non-productive work to justify not throwing our prior good effort on<br>
>> the trash heap (i.e., backlog)?<br>
>><br>
>> Note, these are devil's advocate points, and I do personally<br>
>> understand the necessity of a measure like this to keep your limited<br>
>> bug-fixing resources focussed on issues where the bug reporter really<br>
>> cares about the outcome, and also to achieve higher signal-to-noise<br>
>> ratio in the bugtracker for issues that are not backlogged. But I<br>
>> would make sure that the period of time before a bug is backlogged is<br>
>> generous (at least a year), and I would advertise that period of time<br>
>> up front on the bugtracker as part of a notice that carefully<br>
>> justifies the measure and which also warns the would-be bug reporter<br>
>> that it is normally a long-term commitment to keep his bug report out<br>
>> of the trash heap if his bug report does not attract the attention of<br>
>> a CMake developer (regardless of whether they are salaried by Kitware<br>
>> or volunteer).<br>
>><br>
>> Also, this whole issue is a clear sign that CMake does not have enough<br>
>> _organized_ bug report evaluation resources at the moment (for example,<br>
>> to simply test and evaluate all patches that appear on the bug<br>
>> tracker).  My impression from all the traffic on this list is the<br>
>> volunteer development community for CMake is growing rapidly, but<br>
>> perhaps you (David) might be able to harness some of that volunteer<br>
>> energy by periodically giving a report on the numbers of unresolved<br>
>> bugs on the bugtracker and asking for volunteers to help with<br>
>> evaluation of those.<br>
>><br>
>> Alan<br>
>><br>
>> __________________________<br>
>> Alan W. Irwin<br>
>><br>
>> Astronomical research affiliation with Department of Physics and Astronomy,<br>
>> University of Victoria (<a href="http://astrowww.phys.uvic.ca" target="_blank">astrowww.phys.uvic.ca</a>).<br>
>><br>
>> Programming affiliations with the FreeEOS equation-of-state<br>
>> implementation for stellar interiors (<a href="http://freeeos.sf.net" target="_blank">freeeos.sf.net</a>); the Time<br>
>> Ephemerides project (<a href="http://timeephem.sf.net" target="_blank">timeephem.sf.net</a>); PLplot scientific plotting<br>
>> software package (<a href="http://plplot.sf.net" target="_blank">plplot.sf.net</a>); the libLASi project<br>
>> (<a href="http://unifont.org/lasi" target="_blank">unifont.org/lasi</a>); the Loads of Linux Links project (<a href="http://loll.sf.net" target="_blank">loll.sf.net</a>);<br>
>> and the Linux Brochure Project (<a href="http://lbproject.sf.net" target="_blank">lbproject.sf.net</a>).<br>
>> __________________________<br>
>><br>
>> Linux-powered Science<br>
>> __________________________<br>
><br>
><br>
> Thanks for your comments, Alan. Your input is always much appreciated<br>
> and valuable to the whole CMake community.<br>
><br>
> I realize that this is a touchy subject, and tried very hard to word<br>
> my messages that went along with this action to make it very clear<br>
> that putting a bug into the 'backlog' is not in the least bit<br>
> permanent. It literally takes just a second to flip a bug back to<br>
> 'assigned' for those bugs that are deemed 'must fix'. The 'backlog' is<br>
> just a bucket (of *open issues* by the way, not closed, and certainly<br>
> not forgotten) that helps us to focus on the ones that are *not* in<br>
> it.<br>
><br>
> I am certainly not slapping anyone in the face, or questioning the<br>
> value of anyone else's time. I do apologize to those of you that felt<br>
> that way.<br>
><br>
> It's a difficult job to coordinate and analyze more than 1,200 open<br>
> issues. I want us to get to the point where we have a usefully small<br>
> set of issues that the CMake developers are focusing on, and yet keep<br>
> the rest around until they may be sufficiently addressed.<br>
><br>
> Once we get into a state such as that, and people realize that going<br>
> to the backlog is not a permanent state of affairs, it won't be quite<br>
> so dramatic as what I've done over the past few days.<br>
><br>
><br>
> Thanks,<br>
> David<br>
</div></div></blockquote></div><br></div>