Philosophy of bug fixing/feature request implementation

In the case if that thread in tracker will be wiped to useful posts only, I copy all that text in here (Original BR thread is here ) pan.Krutilkin Status set to "Unconfirmed", why? Didn't you see the screencast? Or you think it is fake? ------------------------------------------------ Mercado_Negro The current status was set for you when opening the issue. Probably developers haven't looked into it and that's why it hasn't been set to "Confirmed", "Awaiting for feedback", "Not a bug" or "Fix coming soon". As you can see 3 users have confirmed this but like I said probably none of them is one of the developers. Some patience, please. ------------------------------------------------ pan.Krutilkin Mercado_Negro, there is 6 votes already. I just can't get the philosophy of cockos. There are some bugs that are not that important, but they are been fixed in the first order. For example Let us think logically... how many times people "use param modulation" in reaper vs how many times people doing "undo" in reaper? Just to sum things about these bugs: 1) undoing is much more often then param modulation 2) this bug is set to Priority 3, and that one is set to "Priority 10 - Lowest"!!! 3) This one was reported on "07-06-2009 07:07 PM" and that one on "12-06-2009 12:34 PM". This one was 5 days earlier! 4) Here are 6 votes already, there is only 1! 5) Only one day have passed and that bug's state is "Fix Coming Soon" now, 6 days have passed and developers did not even look into it. I understand that some bugs *could* be easier to fix, but if you will just fix all small/simple bugs now, and leave big/mainstream/non-easy-to-fix bugs right until 4.0, that will not make any sense. No sense to post bug reports, no sense to buy reaper, etc... until 4.0 or 5.0, or... and so on ------------------------------------------------ schwa If you want to muse about the philosophy of Cockos please do it in the user forum. We want content in the issue tracker to pertain to tracking issues. ------------------------------------------------ So... here we are. Could you please let us know how you choose what bug will be fixed first, what feature request will be implemented first. Because, when issue tracker appeared, I was thinking it is all about priority and user votes. But now I understand that it is not true.

Bug not fixed after six days? Man, I can see your points, but still... six days? I'd be glad to see generic commercial company to act as Cockos does. Not that they are not commercial. I'd give it just a few more days. BTW: I use undo often and never have any problem, probably different circumstances. In that case comparing it like "undoing is much more often then param modulation" is half a truth. Of course I support fast bug fixing, that's what votes are for indeed. But judging the philosophy by 6 days is a bit overkill in my eyes. :-)

my few random thoughts about this: * i've read somewhere that ppl can wait patiently approx. 17 seconds before they press the "call" button AGAIN for the elevator (while still knowing it wont help, the elevator is already coming..) * there are at least 2 ooold FR threads i know of w/ 8000+ views, tons of +1 (+100, etc)'s - and they are still not implemented * im an unpatient kind of a user too * being unpatient means a bad habit * Cockos devs are very very fast and * they do their best, but * they are artists. (imo) :) oh, one more: * compare Cockos' speed w/ the other DAWs/companies..

Your post is misleading pan, you make it sound like undo is unusable. I don't know exactly what the bug you speak of is, but Undo works alright here. Perhaps I haven't tried specifically to Undo the same things as you but I moved some items around, set play and undid them while it played - no problem. I think you must accept there are some states where undo will stop play or make a sound if the action is affects the audio engine

For me, the main issue here is one of trust. Sure, there are feature requests that I personally would like to see today and it would be easy to get disappointed when I see other features which are of no use to me personally being implemented ahead of those that I'd like. But at the same time I trust that Justin, Schwa and co. are able to see the bigger picture and juggle around all the many, many aspects that go into determining priorities. We REAPER users are incredibly lucky to have what I believe to be the most responsive DAW software team there is, certainly that I have ever encountered. I find some of the comments made by the OP quite saddening, and certainly unnecessarily belligerent.

I think what happened with your bug is that it was actually two bugs, one of which was fixed shortly after the bug report. So the bug we saw was fixed, but the bug you saw was not fixed. I've moved the issue back to "open bugs."