Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
Colloquy http://colloquy.info/downloads.html works well for me. On Aug 14, 2012, at 10:18 AM, David Cole wrote: Sorry about that -- I did indeed miss that you were asking to chat with me by IRC or some other IM. How about just a G+ chat session? Or can you recommend a Mac or Windows IRC client I could use? On Tue, Aug 14, 2012 at 11:12 AM, Amine Khaldi amine.kha...@reactos.org wrote: Hello, I missed to reply to all, in my reply, and I only found out after receiving no reply from David even though he's been replying in the list (so this must be some policy that I'm not aware of). Here goes: Original Message Subject: Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse Date: Mon, 13 Aug 2012 15:30:34 +0100 From: Amine Khaldi amine.kha...@reactos.org To: David Cole david.c...@kitware.com Hi David, I certainly did not mean to offend anyone with my en masse move of issues to 'backlog' -- thanks for speaking up. I would like to make sure that you guys can continue to use CMake for ReactOS. Thank you, we were surprised to see the long awaited bugs simply disappear, we thought there are just more important things that you guys are working on, so we were patient. I've got to run right now, but I will reply again tomorrow when I have some more time. Do you have time for a quick phone call or Google+ hangout this week sometime, so I can understand better what your issues are? (And why nobody adopted them when they appeared on the mailing list in the form of your bug reports...) Due to my net speed, I'm afraid the best we can do is a realtime text conversation, so if irc or any other IM is an option, please let me know and I'll be ready. Thank you, Amine. -- 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 -- 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 -- 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
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
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.c...@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.c...@kitware.com wrote: 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
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
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, David On Sun, Aug 12, 2012 at 9:36 PM, Doug douglas.lin...@gmail.com wrote: Just idly, I wonder how practical it would be to automatically close bugs older than XXX time that haven't been touched or assigned. If nothing else it'd generate a notification to the submitter of the bug that either the bug was over looked or not considered important and deserves some discussion if they want it fixed. I've read a few articles online about doing this sort of thing to clear the 'fog' of irrelevant issues that clogs up bug trackers, esp. public ones. ~ Doug. On Sun, Aug 12, 2012 at 8:10 PM, David Cole david.c...@kitware.com wrote: I certainly did not mean to offend anyone with my en masse move of issues to 'backlog' -- thanks for speaking up. I would like to make sure that you guys can continue to use CMake for ReactOS. I've got to run right now, but I will reply again tomorrow when I have some more time. Do you have time for a quick phone call or Google+ hangout this week sometime, so I can understand better what your issues are? (And why nobody adopted them when they appeared on the mailing list in the form of your bug reports...) Thanks, David Cole On Sat, Aug 11, 2012 at 9:42 PM, Amine Khaldi amine.kha...@reactos.org wrote: Hello folks, I would like to mention that many (if not all) the bugs coming from us (ReactOS) got into backlog. We're an operating system project, we try to file bug report only for issues that block us, so we do not tend to file trivial bugs. It would be great if the CMake folks tried to pay the attention that our issues deserve.. after all, we started using CMake because we read many positive reviews about the excellent support. Unfortunately, we're not able to use the VS generators due to the lack of support for ASM preprocessed files. We're not able to pass flags to C/C++ source files without affecting the rc (resource) files. We're forced to do many ugly workarounds for the latter, and we found no solution for the former, and these are just examples. All these mentioned issues got into the backlog, so basically we're left off, without any help to get them solved. I'm writing this hopefully as a call to the CMake folks/community to address our issues, that we've been waiting release after release to get them fixed, only to find out that they ended up in backlog now. I'm writing this in the hopes of finding a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing. Regards, Amine. -- 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 -- 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 -- 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 -- 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:
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
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 __ -- 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
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
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
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
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.c...@kitware.com wrote: 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
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
On 2012-08-13 17:23-0400 David Cole wrote: 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. I think the politics of this could be considerably eased if you also put a prominent announcement of what the backlog classification means on the first page of the bug tracker. 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 __ -- 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
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
Just idly, I wonder how practical it would be to automatically close bugs older than XXX time that haven't been touched or assigned. If nothing else it'd generate a notification to the submitter of the bug that either the bug was over looked or not considered important and deserves some discussion if they want it fixed. I've read a few articles online about doing this sort of thing to clear the 'fog' of irrelevant issues that clogs up bug trackers, esp. public ones. ~ Doug. On Sun, Aug 12, 2012 at 8:10 PM, David Cole david.c...@kitware.com wrote: I certainly did not mean to offend anyone with my en masse move of issues to 'backlog' -- thanks for speaking up. I would like to make sure that you guys can continue to use CMake for ReactOS. I've got to run right now, but I will reply again tomorrow when I have some more time. Do you have time for a quick phone call or Google+ hangout this week sometime, so I can understand better what your issues are? (And why nobody adopted them when they appeared on the mailing list in the form of your bug reports...) Thanks, David Cole On Sat, Aug 11, 2012 at 9:42 PM, Amine Khaldi amine.kha...@reactos.org wrote: Hello folks, I would like to mention that many (if not all) the bugs coming from us (ReactOS) got into backlog. We're an operating system project, we try to file bug report only for issues that block us, so we do not tend to file trivial bugs. It would be great if the CMake folks tried to pay the attention that our issues deserve.. after all, we started using CMake because we read many positive reviews about the excellent support. Unfortunately, we're not able to use the VS generators due to the lack of support for ASM preprocessed files. We're not able to pass flags to C/C++ source files without affecting the rc (resource) files. We're forced to do many ugly workarounds for the latter, and we found no solution for the former, and these are just examples. All these mentioned issues got into the backlog, so basically we're left off, without any help to get them solved. I'm writing this hopefully as a call to the CMake folks/community to address our issues, that we've been waiting release after release to get them fixed, only to find out that they ended up in backlog now. I'm writing this in the hopes of finding a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing. Regards, Amine. -- 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 -- 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 -- 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
[cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
Hello folks, I would like to mention that many (if not all) the bugs coming from us (ReactOS) got into backlog. We're an operating system project, we try to file bug report only for issues that block us, so we do not tend to file trivial bugs. It would be great if the CMake folks tried to pay the attention that our issues deserve.. after all, we started using CMake because we read many positive reviews about the excellent support. Unfortunately, we're not able to use the VS generators due to the lack of support for ASM preprocessed files. We're not able to pass flags to C/C++ source files without affecting the rc (resource) files. We're forced to do many ugly workarounds for the latter, and we found no solution for the former, and these are just examples. All these mentioned issues got into the backlog, so basically we're left off, without any help to get them solved. I'm writing this hopefully as a call to the CMake folks/community to address our issues, that we've been waiting release after release to get them fixed, only to find out that they ended up in backlog now. I'm writing this in the hopes of finding a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing. Regards, Amine. -- 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
