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

David Cole david.cole at kitware.com
Tue Aug 14 13:02:09 EDT 2012


An update and clarification of one of my simple facts: :-)

  - There are presently 1,207 "open issues" in the CMake bug tracker,

  but "open" in this number also includes already "resolved" bugs, of which
there are presently 193.

So, really, there are 1,014 open issues that require work to resolve them...


Thx,
David


On Mon, Aug 13, 2012 at 5:27 PM, David Cole <david.cole at kitware.com> wrote:

> Here are some simple facts:
>
>   - There are presently 1,204 open issues in the CMake bug tracker.
>
>   - We averaged 111 days per release from CMake 2.8.1 to CMake 2.8.9.
>
>   - Each release contained an average of 79 bug fixes from 2.8.3 to 2.8.9.
>
> Hence...... I have a strong desire to focus in on approximately 79
> bugs for the CMake 2.8.10 release, and shelve the remaining 1,125 bugs
> for future consideration.
>
> What we're doing here with the 'backlog' category is simply a focusing
> effort.
>
>
> Thank you,
> David
>
>
> On Mon, Aug 13, 2012 at 5:23 PM, David Cole <david.cole at kitware.com>
> wrote:
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20120814/4c96d8ff/attachment.html>


More information about the cmake-developers mailing list