On Mon, Aug 13, 2012 at 3:37 PM, Alan W. Irwin <ir...@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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers