Re: [CMake] CMake bug tracker discussion
On Friday 10 December 2010, Alan W. Irwin wrote: On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote: On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. I completely agree. Time-based automatic bug closing is a bad idea. On the other hand, on KDE, when we moved to KDE4, we closed almost all KDE3-related bugs without checking if they had been fixed. It did not made too much sense to keep bug reports around unless they were feature requests. That sounds like you would support version-based (as opposed to time-based) bug report closing. The switch from KDE3 to KDE4 involved a major rewrite, so there it made sense to close the KDE3 ones. CMake doesn't have a major rewrite currently, so the situation is different here. Alex ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On Friday 10 December 2010, Bill Hoffman wrote: There are a few things we have already started to do that should help with the bug tracker issue. 1. We hare having 4 releases of CMake each year. After each release we post to the list and ask people to vote for bugs they would like fixed in the next release. 2. We are now sending all new bugs to the cmake-developer list. This way any CMake developer can start working on them or at least know about them when the are opened. I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. I don't really like it. Or at least I think 6 months is quite short. At least for me, e.g. I know that early this year I was working on the Symbian stuff, but didn't finish it. But it is still on my TODO, not forgotten at all. I think it should be at least one year of inactivity. Alex ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
There are a few things we have already started to do that should help with the bug tracker issue. 1. We hare having 4 releases of CMake each year. After each release we post to the list and ask people to vote for bugs they would like fixed in the next release. 2. We are now sending all new bugs to the cmake-developer list. This way any CMake developer can start working on them or at least know about them when the are opened. I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. -Bill ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. On the other hand, on KDE, when we moved to KDE4, we closed almost all KDE3-related bugs without checking if they had been fixed. It did not made too much sense to keep bug reports around unless they were feature requests. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On 12/10/2010 11:01 AM, Pau Garcia i Quiles wrote: On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffmanbill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. Right, and by closing that bug after six months with a message like: If you are still interested in this issue, please re-open and comment. You may want to bring this issue up on the CMake mailing list as well. I am thinking that issues like 8707 would not be forgotten because they would be re-opened and eventually addressed. So, by closing the issue, it would keep the issues from getting stale. -Bill ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
Mantis lets you customize bug resolution. Maybe a new category of resolution could be created. Instead of Won't Fix it could be Lack of Activity? David From: cmake-boun...@cmake.org [cmake-boun...@cmake.org] On Behalf Of Bill Hoffman [bill.hoff...@kitware.com] Sent: Friday, December 10, 2010 09:31 To: Pau Garcia i Quiles Cc: cmake@cmake.org Subject: Re: [CMake] CMake bug tracker discussion On 12/10/2010 11:01 AM, Pau Garcia i Quiles wrote: On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffmanbill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. Right, and by closing that bug after six months with a message like: If you are still interested in this issue, please re-open and comment. You may want to bring this issue up on the CMake mailing list as well. I am thinking that issues like 8707 would not be forgotten because they would be re-opened and eventually addressed. So, by closing the issue, it would keep the issues from getting stale. -Bill ___ 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://www.cmake.org/mailman/listinfo/cmake ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On 12/10/2010 12:48 PM, Thompson, David C wrote: Mantis lets you customize bug resolution. Maybe a new category of resolution could be created. Instead of Won't Fix it could be Lack of Activity? It would have to be something that made it clear, that unless someone cares enough to re-open it, it is not going to be fixed. I sort of like closed, with a special comment that explains why it is being closed, and how to re-open it. -Bill ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote: On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. I completely agree. Time-based automatic bug closing is a bad idea. On the other hand, on KDE, when we moved to KDE4, we closed almost all KDE3-related bugs without checking if they had been fixed. It did not made too much sense to keep bug reports around unless they were feature requests. That sounds like you would support version-based (as opposed to time-based) bug report closing. To be specific what would you think of a new bugtracker policy to close all bugs automatically that were submitted for old versions of CMake with the message, please reopen this bug if it still applies to CMake-2.N? Such a policy seems reasonable to me (especially if the old version cutoff is sufficiently in the past, e.g., close all bugs relevant to CMake-2.N-2 when the 2.N series starts) and avoids the implicit bad message to bug reporters of a time-based policy that we both dislike so much. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On Fri, Dec 10, 2010 at 7:56 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On the other hand, on KDE, when we moved to KDE4, we closed almost all KDE3-related bugs without checking if they had been fixed. It did not made too much sense to keep bug reports around unless they were feature requests. That sounds like you would support version-based (as opposed to time-based) bug report closing. To be specific what would you think of a new bugtracker policy to close all bugs automatically that were submitted for old versions of CMake with the message, please reopen this bug if it still applies to CMake-2.N? Such a policy seems reasonable to me (especially if the old version cutoff is sufficiently in the past, e.g., close all bugs relevant to CMake-2.N-2 when the 2.N series starts) and avoids the implicit bad message to bug reporters of a time-based policy that we both dislike so much. That looks reasonable to me for plain bugreports but not for feature requests or any bugreport which includes a proposed patch -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
2010/12/10 Bill Hoffman bill.hoff...@kitware.com: There are a few things we have already started to do that should help with the bug tracker issue. 1. We hare having 4 releases of CMake each year. After each release we post to the list and ask people to vote for bugs they would like fixed in the next release. 2. We are now sending all new bugs to the cmake-developer list. This way any CMake developer can start working on them or at least know about them when the are opened. This was a very good idea. I would suggest that each reporter get the follow-up of the bug he posted, I think (but I have no way to verify that) that bug reporters do not get automatic e-mail follow-up for each comment posted to their bug unless they add themselves as monitor. I'm using this default behavior for other opens source project bug tracker and I usually get fast answers (including I have no time/mean to answer) on bug comments. Knowing that, If a bug reporter does not react to a comment posted on his bug I would usually tend to stop working on this bug because of the lack of info and let the bug close itself after a grace period. I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. I would prefer having 2 messages: One after 6 monthes of inactivity (i.e. no new comments etc...) saying the bug will be automatically closed a month later unless the situation evolves A second one closing it if no activity is seen after the grace period. Those message should be sent to the monitor list AND the bug reporter. The first message should be didactic, and may be explain that a bug is more easily fixed with the involvement of the reporter: - test case - patch etc -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
Bug trackers make people accountable and make it easy for tasks to be delegated and tracked. BUT, someone has to take on the responsibility of assigning bugs as the come in and/or closing bugs/feature requests that aren't going to be developed on any time soon, thus keeping the number of bugs in the tracker manageable. On Thu, Dec 9, 2010 at 5:06 PM, David Cole david.c...@kitware.com wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. What do you say? David Cole Kitware, Inc. ___ 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://www.cmake.org/mailman/listinfo/cmake ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. What do you say? I like the current system. Especially when you asked a few months ago for what bugs we really wanted to see addressed for the next release. John ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On Thu, Dec 9, 2010 at 11:06 PM, David Cole david.c...@kitware.com wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. What do you say? Interestingly, a very related thread was recently started by a former KDE developer who is now a Mozilla developer: http://thread.gmane.org/gmane.comp.kde.devel.general/62171 My opinion: I like having both a mailing list and a bug tracker. However, I feel not enough attention is paid to the bug tracker. For instance, I requested a feature and provided a patch almost two years ago and I've heard nothing: http://public.kitware.com/Bug/view.php?id=8707 I guess it's an issue of not enough manpower. Given that Kitware does not make money directly from CMake, I understand you cannot invest in having people dedicated exclusively to this. Nokia is suffering a similar problem with Qt (it's just too big for them to maintain everything on every platform they support). Their (proposed) solution? Outsource some things to the community, i. e. let people not from Nokia work on stuff they want and have a loose acceptance policy. Maybe you could start by having some people from outside of Kitware (apart from Alex ;-) ) help with triaging bugs and commit patches and not-too-complex features. Also, having a public and clear roadmap and release dates is appreciated. I think 2.8.4 is the first release I actually know what is being worked on and when it is going to be released. I would like to know what the long-term vision and plans are: what platforms and languages would you would like to support, what fundamental changes you plan to make, what things you will never accept, what would you like to see but do not have/cannot justify the time/resources to do and would like the community to help you with, etc Oh, and one more request for the bugtracker, related to what I just said: a vote system, so that people can vote for features/bugfixes/etc they feel important. You may (or may not) be surprised to discover something is considered very important by a lot of people. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On Thu, Dec 9, 2010 at 5:06 PM, David Cole david.c...@kitware.com wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I like the bug tracker. Even people that use it, however, know that hitting up the mailing list tends to improve the chance that the bug is actually researched and fixed. Also, sometimes it seems wrong to take an issue raised on the mailing list and force it into the bug tracker. It seems a little rude to the person that emailed about the issue because you might be asking them to deal with the rigmarole of creating a mantis account when they already went through the hassle of joining the mailing list and making the post. -- Philip Lowman ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On 2010-12-09 17:06-0500 David Cole wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. I am glad you brought this subject up because there is a real problem engulfing CMake's bug tracker as we speak. It appears from the resolved category of CMake bugs on the bug tracker, that ~10 bugs were resolved (not necessarily fixed) in November, but that same month saw ~50 new bugs reported (to the cmake-devel mailing list). That ratio of 5 new bugs for every one resolved means the CMake bug tracker is rapidly being filled with unresolved issues with no hope of ever resolving them unless some substantial changes are made. Here are some ideas to help reduce that insanely unsustainable ratio of five down to a sustainable unity. 1. Reduce the number of new bug reports. a. My guess is lots of those new bug reports are noise due to misunderstanding of how to use CMake (despite what I consider to be outstanding documentation). So reduce the numbers by strongly suggesting that all potential bugs should be discussed first on the mailing list (with [BUG?] in the subject line to draw attention to it) to make sure they really are bugs before writing up a bug report. b. Avoid using the bug tracker whenever possible, e.g., quick and obvious fixes. I have experienced other organizations which demanded everything go to the bugtracker where posting to the bugtracker became the point rather than actually fixing bugs. In other words, bug trackers have been used by some organizations as an excuse for inaction on bugs! This is clearly not the case with the CMake developers (I just this morning had one of my discussed bugs fixed without going through the bug tracker), but I feel strongly about that important pitfall of bugtrackers so I brought it up explicitly here. It should be emphasized that bug trackers can play an important role for the more difficult fixes that take a lot of experimentation and thought to get right, but in my view creating a bug report on a bug tracker has an obvious cost for the reporter and for the bug triage team afterward so should be avoided for the simple stuff. 2. Increase the resources you spend on resolving bugs in the bug tracker. a. More community involvement, e.g., encourage a community bugfix team whose principal job was to do the first-level bug triage such as investigating the questions of whether it is a well-posed bug report (e.g., is there enough information in the bug report), is the issue reproducible, and ultimately is it a real bug or not. And if not, members of that team would have the power to close the bug as not a bug. b. A modest increase in Kitware resources devoted to bug fixing. This is obviously a judgement call that is up to Kitware, but if I had a say in Kitware's allocation of resources, this is how I would argue for these additional resources. Kitware doesn't get direct money for their CMake development efforts, but CMake is an enormous boost to their reputation which presumably translates to more commercial success through their paid-for products. The bottom line is ultimately it hurts Kitware's reputation if their CMake bugtracker is filled to the brim with unresolved issues so some increase in Kitware resources as well as encouraging community involvement is warranted to help deal with the current bad situation. In sum, I agree with the others who have posted on this question that you need both mailing-list discussion of all bugs and the bugtracker. My additional ideas beyond that general idea are (1) you should encourage mailing list discussion to make sure a CMake problem some user is having is really due to a bug, and (b) make a conscious effort to make quick fixes when those are warranted, and (c) encourage use of the bug tracker only for the more difficult issues where there is obviously no quick fix. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming
Re: [CMake] CMake bug tracker discussion
On Thu, Dec 9, 2010 at 7:09 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-12-09 17:06-0500 David Cole wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. I am glad you brought this subject up because there is a real problem engulfing CMake's bug tracker as we speak. It appears from the resolved category of CMake bugs on the bug tracker, that ~10 bugs were resolved (not necessarily fixed) in November, but that same month saw ~50 new bugs reported (to the cmake-devel mailing list). That ratio of 5 new bugs for every one resolved means the CMake bug tracker is rapidly being filled with unresolved issues with no hope of ever resolving them unless some substantial changes are made. A couple of points to alleviate (or at least reduce your concerns) about this trend. (1) It's not as bad as you think based on November alone. In the last 365 days, 589 bugs have been opened and 341 have been resolved. Net increase in open bugs of 248 over the last year. So ratio of new-bugs:resolved-bugs is actually about 1.7:1. (2) Having spent much of my own time perusing bugs in the CMake bug tracker, I can tell you that the 0.7 over the 1 that makes up that 1.7:1 ratio are noise or duplication or just not worth anyone's time. So the ratio is more even than you think, and I don't think we need a major adjustment in this respect. I've gotta digest the rest of what you said. Maybe more reply to come later. :-) Thanks for the input, David Here are some ideas to help reduce that insanely unsustainable ratio of five down to a sustainable unity. 1. Reduce the number of new bug reports. a. My guess is lots of those new bug reports are noise due to misunderstanding of how to use CMake (despite what I consider to be outstanding documentation). So reduce the numbers by strongly suggesting that all potential bugs should be discussed first on the mailing list (with [BUG?] in the subject line to draw attention to it) to make sure they really are bugs before writing up a bug report. b. Avoid using the bug tracker whenever possible, e.g., quick and obvious fixes. I have experienced other organizations which demanded everything go to the bugtracker where posting to the bugtracker became the point rather than actually fixing bugs. In other words, bug trackers have been used by some organizations as an excuse for inaction on bugs! This is clearly not the case with the CMake developers (I just this morning had one of my discussed bugs fixed without going through the bug tracker), but I feel strongly about that important pitfall of bugtrackers so I brought it up explicitly here. It should be emphasized that bug trackers can play an important role for the more difficult fixes that take a lot of experimentation and thought to get right, but in my view creating a bug report on a bug tracker has an obvious cost for the reporter and for the bug triage team afterward so should be avoided for the simple stuff. 2. Increase the resources you spend on resolving bugs in the bug tracker. a. More community involvement, e.g., encourage a community bugfix team whose principal job was to do the first-level bug triage such as investigating the questions of whether it is a well-posed bug report (e.g., is there enough information in the bug report), is the issue reproducible, and ultimately is it a real bug or not. And if not, members of that team would have the power to close the bug as not a bug. b. A modest increase in Kitware resources devoted to bug fixing. This is obviously a judgement call that is up to Kitware, but if I had a say in Kitware's allocation of resources, this is how I would argue for these additional resources. Kitware doesn't get direct money for their CMake development efforts, but CMake is an enormous boost to their reputation which presumably translates to more commercial success through their paid-for products. The bottom line is ultimately it hurts Kitware's reputation if their CMake bugtracker is filled to the brim with
Re: [CMake] CMake bug tracker discussion
...Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? ... - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? Tradeoffs between push (mailing list) vs pull (bug tracker) seem like a very person-specific preference. Why enforce one or the other? Also, I know it's slightly off-topic, but it seems like the alternatives you're offering are what people use frequently today as opposed to the way things should be (and what new tools are under development in those directions). For example I've been using ditz (a distributed bug tracker that uses git or hg to manage bugs) on a small project lately and enjoying it. It's not polished or maintained enough to warrant using it on a large project, but I mention it because I think it's an indication of how bug tracking might change over the next few years... It would be nice to have local bugs that I don't push to the community but which help me track my own progress. I also happen to think that, besides becoming distributed, bug tracking systems will change in another way: they will more clearly differentiate between technical vs. narrative bug reports and handle both types. Currently, the strategies for handling bug reports from users is either (a) users can file bugs and many useless reports are filed or (b) users cannot file bugs and many problems are never brought to the attention of developers. I suspect (if it hasn't already happened) that a system for collecting **and mining** narrative reports (as told in the voice of the user, many stack traces with similar failures, etc.) will be developed that can tie to a technical issue tracker that is curated by developers (details of the problem and progress on it). My 1 to 3 cents, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake bug tracker discussion
On 2010-12-09 19:23-0500 David Cole wrote: On Thu, Dec 9, 2010 at 7:09 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-12-09 17:06-0500 David Cole wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. I am glad you brought this subject up because there is a real problem engulfing CMake's bug tracker as we speak. It appears from the resolved category of CMake bugs on the bug tracker, that ~10 bugs were resolved (not necessarily fixed) in November, but that same month saw ~50 new bugs reported (to the cmake-devel mailing list). That ratio of 5 new bugs for every one resolved means the CMake bug tracker is rapidly being filled with unresolved issues with no hope of ever resolving them unless some substantial changes are made. A couple of points to alleviate (or at least reduce your concerns) about this trend. (1) It's not as bad as you think based on November alone. In the last 365 days, 589 bugs have been opened and 341 have been resolved. Net increase in open bugs of 248 over the last year. So ratio of new-bugs:resolved-bugs is actually about 1.7:1. I am glad to hear the ratio averaged over this entire year is lower than 5 although I would still argue (see below) that 1.7 is not sustainable. (2) Having spent much of my own time perusing bugs in the CMake bug tracker, I can tell you that the 0.7 over the 1 that makes up that 1.7:1 ratio are noise or duplication or just not worth anyone's time. I am not surprised by that large noise factor at all. However, I do believe those noise bug reports are worth someone's time in the sense that they should be dealt with (closed) as quickly as possible. Otherwise, those trying to stay on top of the bug tracker by scanning through the various unresolved bug reports will start getting turned off by this noise, become less efficient, etc. That's why I argue above that the ratio of new bugs to resolutions must be unity (or ideally lower to start whittling away at the backlog) or else the bugtracker is unsustainable in the long run. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ 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://www.cmake.org/mailman/listinfo/cmake
