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 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 > wrote: > > On Mon, Aug 13, 2012 at 3:37 PM, Alan W. Irwin > > 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). > >> > >> Pro
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 > 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 > To: David Cole > > 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
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
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 wrote: > On Mon, Aug 13, 2012 at 3:37 PM, Alan W. Irwin > 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
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 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 jo
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
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 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 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 >> 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
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 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 > 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
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
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 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
[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
