Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On May 17, 2007, at 9:19 PM, Björnke von Gierke wrote: Of course with such small numbers, one can not really draw a conclusive decision, I think the answer to how successful this release and any other release is will be very subjective. I don't think it is reasonable to expect the bug count to change by a given percentage. I was one of the people that gave this release rave reviews simply because I can see and feel the difference from this version and my previous reliable 2.7.4. I still have bugs that are over 2 years old that have not been fixed. I have bugs that were only days old that did get fixed. In my very subjective measure, 2.8.1 is a huge step forward when I look at the projects I am working on and how they perform. Everyone's mileage will vary when it comes to gaging how significant a given release is. If I am able to produce the commercial projects I am working on then all is good from my perspective. Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Completely agree with you, Mark! As a relatively new user of Revolution 2 years (with a few software projects completed during this time which would not be possible without Rev) I was also extremely satisfied to see Altuit products eventually integrated into the IDE. Now it is not anymore a buy-in-pieces-puzzle that was very frustrating for me as a newcomer to Rev at that time. I see this as a major quality and end users experience improvement for any newcomer ! Meanwhile I would like to attract few votes for bug 4677, or now it is confirmed and marked as a duplicate of 441 which is partially solved for some languages, but not for mine :-) The problem is that characters outside of the standard Western European character set are not being translated correctly during keyboard entry, therefore I can't do projects in my native and a few other national languages... And bug 3992 - it is confirmed, and is still in the latest release candidate of open beta. If briefly - property inspector loads file contents into wrong unrelated text fields replacing their contents and thus damaging data. If you are new to the IDE you may get deeply depressed after seeing this ;-), later you learn and get used to put url file:etc into field etc and forget that the problem is there. Nevertheless I think it is important. I have also voted for bug 2498. It causes situation where 2 tabbed buttons put on same card do interfere with each other on mouseover event. Not a big tragedy but looks messy (e.g. in a spreadsheet which is a part of a larger application with tabbed buttons)... All the best! Viktoras ---Original Message--- From: Mark Talluto Date: 18/05/2007 09:26:11 To: How to use Revolution Subject: Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879? On May 17, 2007, at 9:19 PM, Bjrnke von Gierke wrote: Of course with such small numbers, one can not really draw a conclusive decision, I think the answer to how successful this release and any other release is will be very subjective. I don't think it is reasonable to expect the bug count to change by a given percentage. I was one of the people that gave this release rave reviews simply because I can see and feel the difference from this version and my previous reliable 2.7.4. I still have bugs that are over 2 years old that have not been fixed. I have bugs that were only days old that did get fixed. In my very subjective measure, 2.8.1 is a huge step forward when I look at the projects I am working on and how they perform. Everyone's mileage will vary when it comes to gaging how significant a given release is. If I am able to produce the commercial projects I am working on then all is good from my perspective. Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On 18 May 2007, at 05:30, Chipp Walters wrote: Heck, I wrote that demo and even I can't figure out what this guy is saying! Surely that's where two way communication comes in handy? Cheers, Luis. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On May 17, 2007, at 11:36 PM, Bill Marriott wrote: - Even when version 2.9 is released, it will still have bugs. Every product more complex than a coffee mug has bugs. Ahem! I beg to differ: groan http://www.collectorsconnection.com/imagesh1/39a308.jpg /groan Devin Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
I understand what you're saying, but my statement was concerned with the fact that it was your demo: Not knowing what the demo was I opted for the general view that this was reported by a standard user, who is often naive, which I judged from the 'bug report'. Most naive users do not understand the 'bug reporting process' and many do not want to be educated because they see no benefit to it: They just want to play the game (or whatever the app is). Cheers, Luis. On 18 May 2007, at 16:45, Chipp Walters wrote: On 5/18/07, Luis [EMAIL PROTECTED] wrote: On 18 May 2007, at 05:30, Chipp Walters wrote: Heck, I wrote that demo and even I can't figure out what this guy is saying! Surely that's where two way communication comes in handy? With Rev having hundreds of bugs to go through, anyone serious about getting their bug fixed would be wise to create: 1) a clear explanation of the bug 2) a recipe for replcating it 3) if possible, a demo stack showing it Furthermore, those who wish their bugs fixed can also do a bit of research by contacting other developers here to confirm the bug before posting it. Typically, when I discover a bug in Rev, I try first to break it down into it's simplest components and try and create the most straightforward and basic recipe for repeating it. Then I create a simple bug demo stack, post it online and ask others to verify it. Once verified, I then post the bug, with the stack, to bugzilla. I have found this methodology has enabled most all of my reported bugs to be fixed in a very timely matter. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On 5/18/07, Luis [EMAIL PROTECTED] wrote: On 18 May 2007, at 05:30, Chipp Walters wrote: Heck, I wrote that demo and even I can't figure out what this guy is saying! Surely that's where two way communication comes in handy? With Rev having hundreds of bugs to go through, anyone serious about getting their bug fixed would be wise to create: 1) a clear explanation of the bug 2) a recipe for replcating it 3) if possible, a demo stack showing it Furthermore, those who wish their bugs fixed can also do a bit of research by contacting other developers here to confirm the bug before posting it. Typically, when I discover a bug in Rev, I try first to break it down into it's simplest components and try and create the most straightforward and basic recipe for repeating it. Then I create a simple bug demo stack, post it online and ask others to verify it. Once verified, I then post the bug, with the stack, to bugzilla. I have found this methodology has enabled most all of my reported bugs to be fixed in a very timely matter. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On 5/18/07, Luis [EMAIL PROTECTED] wrote: I understand what you're saying, but my statement was concerned with the fact that it was your demo: Not knowing what the demo was I opted for the general view that this was reported by a standard user, who is often naive, which I judged from the 'bug report'. Most naive users do not understand the 'bug reporting process' and many do not want to be educated because they see no benefit to it: They just want to play the game (or whatever the app is). Reading an earlier message may have told you it had something to do with altSQLite, which is no longer 'my demo,' other than the fact I wrote it before selling it to RR. This was literally the FIRST bug I clicked on marked UNCONFIRMED, and not one I was looking at. I found it amusing it had something to do with a product I wrote (and have had very few complaints about.) My point was to show all bugs are not created equal. How do you resolve a bug which starts: RunRev doesn't work. --user What's the problem. --RR It's broken -user How can I help? --RR When I step on the pedal, it doesn't go forward! -user That's the mouse, and you're not supposed to step on it -RR My only thought is I'd rather RR spend their valuable and precious bug-resolving resources on bugs which are clearly delineated. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Great advice, Chipp. As one who recently had two or three bugs fixed directly due to my efforts, it really happens. What helped immensely was that I included a video clip to show events leading up to the problem, and a talking narrative at the same time. Also the crash reports furnished by the operating systeme are invaluable. I always try to get a nice 'package' together before making a report and it really pays off. It took hours, but was well worth it. On the mac, the shareware iShowU is wonderful for this, and if you use the 'apple animation' codec, the files can be quite small. http://www.shinywhitebox.com/home/home.html - it's $20 and with a $40 USB headset you can make pro quality how-to videos of any size. I found the audio out of the headset (logitech at Radioshack) was more appropriate and intelligible than any of my pro vintage microphones. With Rev having hundreds of bugs to go through, anyone serious about getting their bug fixed would be wise to create: 1) a clear explanation of the bug 2) a recipe for replcating it 3) if possible, a demo stack showing it Furthermore, those who wish their bugs fixed can also do a bit of research by contacting other developers here to confirm the bug before posting it. Typically, when I discover a bug in Rev, I try first to break it down into it's simplest components and try and create the most straightforward and basic recipe for repeating it. Then I create a simple bug demo stack, post it online and ask others to verify it. Once verified, I then post the bug, with the stack, to bugzilla. I have found this methodology has enabled most all of my reported bugs to be fixed in a very timely matter. -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Chipp, I think you may be drawing the wrong lesson. Of course the bug you mention is not useful. The problem is that the database contains it. That tells you something. Bill's remark, that the database contains lots of stuff that is already fixed also tells you something. Its good news and bad news, its good about the bugs. Its less good about the database. People have enormous goodwill towards Rev. They will accept realistic targets that are met, even if those targets are less than what they want, and less than what the Rev team wants to deliver. I think part of what Joel is saying may be: pick a quantified realistic goal, communicate it, and stick to it and deliver it. Even if it not what people would have liked, they will like this approach to delivering a given quantity of work much better than any possible alternative. Peter My point was to show all bugs are not created equal. How do you resolve a bug which starts: RunRev doesn't work. --user What's the problem. --RR It's broken -user How can I help? --RR When I step on the pedal, it doesn't go forward! -user That's the mouse, and you're not supposed to step on it -RR My only thought is I'd rather RR spend their valuable and precious bug-resolving resources on bugs which are clearly delineated. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On 5/18/07, Peter Alcibiades [EMAIL PROTECTED] wrote: Chipp, I think you may be drawing the wrong lesson. Of course the bug you mention is not useful. The problem is that the database contains it. That tells you something. Bill's remark, that the database contains lots of stuff that is already fixed also tells you something. Its good news and bad news, its good about the bugs. Its less good about the database. 'That tells you something' -- perhaps I'm just slow, but I'm not sure what that tells me? 'its good news and bad news-good about the bugs, less good about the database' -Again, completely confused at the point you're trying to make. Just to be clear, I was advocating a responsible and logical approach for submitting and/or reporting bugs which if used would create even more integrity in the database. People have enormous goodwill towards Rev. They will accept realistic targets that are met, even if those targets are less than what they want, and less than what the Rev team wants to deliver. I think part of what Joel is saying may be: pick a quantified realistic goal, communicate it, and stick to it and deliver it. Even if it not what people would have liked, they will like this approach to delivering a given quantity of work much better than any possible alternative. Yeah, I know what you mean. I'm still upset about promises broke concerning flying cars and Dick Tracy watches ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On 18 May 2007, at 17:21, Chipp Walters wrote: My point was to show all bugs are not created equal. How do you resolve a bug which starts: RunRev doesn't work. --user What's the problem. --RR It's broken -user How can I help? --RR When I step on the pedal, it doesn't go forward! -user That's the mouse, and you're not supposed to step on it -RR My only thought is I'd rather RR spend their valuable and precious bug-resolving resources on bugs which are clearly delineated. Well, my idea would be to reply (this would be automated) to a bug email (must be sent to the bugs@ address) with a link to a page to fill in the details of the bug. This would constitute a web page with as many options as possible as pull downs, starting from the highest level (choose the software, choose the version) to as low as can fit on one page, so as to not appear a daunting task. If they reach the bottom of the page they have the option to further detail the issue. The pull downs should whittle the chaff away from the problem so the bug reporter now has a better idea of what is required and can now detail the issue in his/her own words. Getting to this point should also assist with any issues regarding non-native speakers. Cheers, Luis. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On May 18, 2007, at 4:05 PM, Luis wrote: Well, my idea would be to reply (this would be automated) to a bug email (must be sent to the bugs@ address) with a link to a page to fill in the details of the bug. This would constitute a web page with as many options as possible as pull downs, starting from the highest level (choose the software, choose the version) to as low as can fit on one page, so as to not appear a daunting task. If they reach the bottom of the page they have the option to further detail the issue. The pull downs should whittle the chaff away from the problem so the bug reporter now has a better idea of what is required and can now detail the issue in his/her own words. Getting to this point should also assist with any issues regarding non-native speakers. RevZilla by Ken Ray does pretty much that. Have you given it a try? It runs right in Rev. http://www.sonsothunder.com/devres/revolution/downloads/RevZilla2.htm Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Had a look at it, but still doesn't offer that many options to drill down the issue: I'm trying to avoid the bug reporter from having to type 'too much'. For example for a graphics app (these would be spread across as well as down the page!): * = Selected Options/Pull downs Your system - OS 9 - OS X* - W98 - W2K - WXP Select product - PictureMe* - PrintMe Select version - v1 - v2 - v3* Problem on Startup or Quit? - Yes - No* Problem with Menu? - Yes - No* Problem with Tools? - Yes* - No Etc, etc. I'd get them tailored to fit the page plus space for the comment (only writeable if the bug reporter has pulled down at least 60% of the options to cater for non-obvious issues not included in the pull downs). Pull downs are little effort, so if someone has bothered to at least report the bug, it shouldn't be too hard. There are plenty of options in RRQC and RevZilla, but I'd rather use up all that screen space to ask as many questions as possible (ie: via the pull downs) to narrow down the issue. Cheers, Luis. On 19 May 2007, at 0:13, Mark Talluto wrote: On May 18, 2007, at 4:05 PM, Luis wrote: Well, my idea would be to reply (this would be automated) to a bug email (must be sent to the bugs@ address) with a link to a page to fill in the details of the bug. This would constitute a web page with as many options as possible as pull downs, starting from the highest level (choose the software, choose the version) to as low as can fit on one page, so as to not appear a daunting task. If they reach the bottom of the page they have the option to further detail the issue. The pull downs should whittle the chaff away from the problem so the bug reporter now has a better idea of what is required and can now detail the issue in his/her own words. Getting to this point should also assist with any issues regarding non-native speakers. RevZilla by Ken Ray does pretty much that. Have you given it a try? It runs right in Rev. http://www.sonsothunder.com/devres/revolution/downloads/ RevZilla2.htm Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On 5/18/07, Luis [EMAIL PROTECTED] wrote: Well, my idea would be to reply (this would be automated) to a bug email (must be sent to the bugs@ address) with a link to a page to fill in the details of the bug. This would constitute a web page with as many options as possible as pull downs, starting from the highest level (choose the software, choose the version) to as low as can fit on one page, so as to not appear a daunting task. If they reach the bottom of the page they have the option to further detail the issue. The pull downs should whittle the chaff away from the problem so the bug reporter now has a better idea of what is required and can now detail the issue in his/her own words. Getting to this point should also assist with any issues regarding non-native speakers. Can you point me to such a system which is currently in use? Thanks. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Luis wrote: On 19 May 2007, at 0:13, Mark Talluto wrote: RevZilla by Ken Ray does pretty much that. Have you given it a try? It runs right in Rev. Had a look at it, but still doesn't offer that many options to drill down the issue: I'm trying to avoid the bug reporter from having to type 'too much'. For example for a graphics app (these would be spread across as well as down the page!): * = Selected Options/Pull downs Your system - OS 9 - OS X* - W98 - W2K - WXP Select product - PictureMe* - PrintMe Select version - v1 - v2 - v3* Problem on Startup or Quit? - Yes - No* Problem with Menu? - Yes - No* Problem with Tools? - Yes* - No Etc, etc. I'd get them tailored to fit the page plus space for the comment (only writeable if the bug reporter has pulled down at least 60% of the options to cater for non-obvious issues not included in the pull downs). Pull downs are little effort, so if someone has bothered to at least report the bug, it shouldn't be too hard. There are plenty of options in RRQC and RevZilla, but I'd rather use up all that screen space to ask as many questions as possible (ie: via the pull downs) to narrow down the issue. Revzilla's written in Rev, so you could make your UI as a wizard for it. I'm sure Ken would be willing to add it to his web page as a Revzilla add-on. Let us know when you have it done. Sounds cool. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Nope, it's in my head. Cheers, luis. On 19 May 2007, at 0:58, Chipp Walters wrote: On 5/18/07, Luis [EMAIL PROTECTED] wrote: Well, my idea would be to reply (this would be automated) to a bug email (must be sent to the bugs@ address) with a link to a page to fill in the details of the bug. This would constitute a web page with as many options as possible as pull downs, starting from the highest level (choose the software, choose the version) to as low as can fit on one page, so as to not appear a daunting task. If they reach the bottom of the page they have the option to further detail the issue. The pull downs should whittle the chaff away from the problem so the bug reporter now has a better idea of what is required and can now detail the issue in his/her own words. Getting to this point should also assist with any issues regarding non-native speakers. Can you point me to such a system which is currently in use? Thanks. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
On 19 May 2007, at 1:13, Richard Gaskin wrote: Revzilla's written in Rev, so you could make your UI as a wizard for it. I'm sure Ken would be willing to add it to his web page as a Revzilla add-on. Let us know when you have it done. Sounds cool. I'll let it float around in my head for now, but thanks. Cheers, Luis. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Dear Revolutionists, A warm thank you very much to Runrev for having fixed more than 240 bugs. I would like to know how successfull is the open beta and what criterion have been defined at the beginning of the quality way last November. It would be interested to get the results of the last open beta anonymous survey. With my background in scientific research let me try to present formally known data about Revolution bugs and make some comments carefully: MOTIVATIONS AND OBJECTIVES: - I have personally reported major or blocking bugs still unresolved nor closed (even more than a year old). - Respectable persons were unfairly flamed for having objectively and politely requested about the quality work and to understand procedures transparently (that's ISO 9xxx quality management procedures, isn't it?). - Public declarations, apologizes and/or promises not to repeat *exceptional* unhappy events from Runrev appeared to me a different story from facts reported by the rev-list and experiences. - Actually I want to get a better picture of what's really the gain of the current quality step initiated by Runrev and then the future I can expect for my favorite IDE. METHOD: - Queries done today (2007-05-17) with the most recent version of stack STSRevZilla. RESULT: - At the time of the queries RevZilla found that 1879 bugs are neither resolved, nor closed: 580 are new, the oldest one was created on 2003-10-28 129 are pending, the oldest one was created on 2003-10-24 1079 are new, the oldest one was created on 2003-06-16 53 are assigned, most are enhancement requests, 2 are major, 1 minor, one norma, the oldest one was created on 2003-06-24 37 are reopened, oldest created on 2003-08-12 1 is verified, created on 2005-06-15. - RevZilla found that 3067 bugs are either resolved or closed: 2729 bugs are marked resolved. 338 bugs are marked closed. - Among the 1879 bugs that are neither resolved, nor closed today: 227 has severity of blocker, critical or major (126 bugs before 2006-11-10 and 103 bugs reported during the open beta process). 821 has severity enhancement. - The Open Community Beta for 2.7.5 has been annonced on November 10th 2006 (http://www.runrev.com/newsletter/november/issue13/ newsletter1.php). - the first bug notified on 2006-11-10 is #3967 (concerning version 2.6.1 it is now resolved/closed). - the first bug notified on 2006-11-10 for version 2.7.5 is #3968 (now closed/not a bug). - since this opening date 1013 bugs have been notified and categorized as followed: 345 bugs have been notified (created) and resolved. 85 bugs have been notified and closed. 584 bugs have been notified but still neither resolved nor closed. COMMENTS: - Remember that some of the bugs notified in revzilla are enhancement requests. - Out of the 1879 remainging reported bugs 584 of them has been reported after the beginning of the open beta, i.e. 1295 bugs reported prior the beta are still uncovered. - It is surprising that as many as 227 bugs marked as blocker, critical or major have not been processed during this quality step. 45% of them have been reported during the open beta process (126 of them were known prior the begining of the open beta and 103 has been reported during the process). - Because stsRevzilla does not let us search the date a bug is closed or resolved then it is simply difficult to compare the results above with the past state of November 2006. This comparison would have been interested in order to answer if Runrev has actually made a progress and how much of its resources it has spent in fixing new bugs introduced during this Open Beta process. Of course you should study this with care because among the 1013 bugs notified since November some are bugs present but not reported in older releases or new bugs introduced between 2.7.4 and the 2.8.1. Have a look to the list of bugs (since #3967) to make your own opinion on the amount of wasted workload the open beta may have self generated. - So, impossible to know how Runrev count the 240+ bugs fixed. - Also a deeper study would be necessary to evaluate how bugs were prioritized in the fix: is priority choosen by severity, by reporter, by date, by vote count? CONCLUSIONS: I dont want to comment on the success of this Open Community Beta. Of course this is not my job but among the other reasons, by rereading the original newsletter article, the objectives are still imprecise to me. So I let you make your own conclusions, positives and negatives, if applicable for you, and in such a context (this is no scientific way) tightly bound to your own expectations I guess. Just a few remarks: 1.- I am thankful to Runrev for trying to make Revolution better quality and to ensure its future. 2.- I was happy to read so much excitements from major revolutionaries to applaude the 2.8.1 release on both the use and improve lists.
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
A well thought out and executed post, Joel. Thanks for that. I read your post twice, and maybe I'm just suffering from post-lunch lag but I couldn't figure out what you were proposing there. What do you suggest? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Joel Guillod wrote: - Also a deeper study would be necessary to evaluate how bugs were prioritized in the fix: is priority choosen by severity, by reporter, by date, by vote count? As I understand it, they decide based on a combination of many things, including all the above (though I don't think the person who reports it matters very much.) Crashing bugs are always high priority. Blockers are difficult to decide, I suspect. If only one person says something is a blocker but the thousands of other users don't, then it is hard to decide whether to give that bug a higher priority than another bug of less severity that affects many people. In this case, votes may help the decision. Also, it is likely that when fixing one segment of the code base, it is easy to fix related bugs at the same time; that means some relatively minor bugs may get fixed simply because the engineers are looking at that segment of code at the moment. Another factor is whether the bugs affect a feature that is scheduled for a rewrite in the future. If a feature is scheduled for a rewrite, it isn't worth fixing related bugs because after the rewrite they won't be relevant any more. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Joel, I, too, read your dissertation, and like Richard couldn't quite grasp what you are getting at. Perhaps a simple paragraph explaining what you're after would help. -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
I guess his point is that he gathered some data, and that by that data the beta was not a huge success at increasing the resolved bugs, as claimed by some. I myself are inclined to agree, because of this: 1879 bugs are not handled 584 bugs of these where entered after the open beta was announced 3067 bugs are handled 430 of these handled bugs where entered after the open beta So 3067 of total 4946 have been handled, that is a percentage of ca. 62% However only 430 of 1014 bugs have been solved during the open beta, making it 42% percent. So the percentage of solved bugs during the beta is actually worse then over all. Another possible comparision: The beta was only ca. 6 month's, and bug 1 was filled June 2003, or ca. 35 months ago. Thus 88 bugs per month where solved overall vs. 72 per month during the beta. This second comparison is a bit closer, but still unfavourable for the beta. Of course with such small numbers, one can not really draw a conclusive decision, because if a person was sick for a month during January 2007 (for example), then the beta would suffer a much bigger setback then the overall score. Still, based on these numbers, stating that the beta was a huge success in solving bugs is certainly an unfounded one, even if it was a success based on other criterias (like the satisfaction poll mentioned by bill some days ago). -- official ChatRev page: http://chatrev.bjoernke.com Chat with other RunRev developers: go stack URL http://homepage.mac.com/bvg/chatrev1.3.rev; ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
Björnke von Gierke wrote: Of course with such small numbers, one can not really draw a conclusive decision, I think any comparisons need to subtract all the pending bugs from any totals. Bugs that are pending can't be addressed until more information is gathered, they are in an indecisive state. Many of them may not really be bugs, but that can't be proven until more info is gathered from the reporter. Pending bugs are more like maybe bugs. I also think all enhancement requests should be removed from the totals. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
I may not know how to use the new quality control center website. I just did a quick search to find all the outstanding bugs with 'major' or 'critical' or 'blocker' assigned. blocker bugs: 160 Resolved or Closed of 191 critical bugs: 195 Resolved or Closed of 244 major bugs:398 Resolved or Closed of 546 This also doesn't count the unconfirmed bugs which make little to no sense, such as this one listed as Major: The table have strange memory effect if I use it with a database. 1) when I press the key populate table the correct data are putting into the table field 2) I click into a cell and appears the old text that I had written before, but I have written these data many days before (during this time I have opened and closed Revolution and the AltuitSQLite3 Db) 3) when i click out of the table field all the old data appear, after if I press the populate table key the correct data is put into the table. I am sure that the database contains only those data why I have controls them with SQLite Browser 1.2.1 Heck, I wrote that demo and even I can't figure out what this guy is saying! From where I sit, it looks like they're doing a pretty good job. It's just my opinion. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
And an even warmer thank you to RunRev for incorporating at least 100 new enhancements into the 2.9 release! (FYI: that's not a slander or flame... it's my hope for the future) I have to say that I was more happy with this open beta then the last one. The main reason, I was actually asked for a list of my top 5 bugs that I want to see resolved. That gave me a voice, and I didn't have to spend my time trying to get people to vote for my bug. AND, the #1 bug on my list was resolved, again (long story). I, personally, find that determining priority for bugs should not be based on how many votes a bug or enhancement may have, and for this specific reason (mind you, I'm in the USA): If there were 1,879 candidates in an election, nearly all of the voters will be unhappy with the elected candidate. I would prefer that bugs and enhancements would be handled like this: - Bugs that are determined to be critical (like crashes and destroyed data) would be handled first, and, resolved for free. - Bugs and Enhancements that are not critical would be taken care of on a first come/first serve basis, with status reports at least once a month. But other than that, I'm really liking the way things are going with Rev. Every year the program gets stronger, and I'm not unhappy with that in the least. Derek Bump Dreamscape Software http://www.dreamscapesoftware.com Joel Guillod wrote: A warm thank you very much to Runrev for having fixed more than 240 bugs. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Revolution 2.8.1: a 240+ bug fixes/improvements! What about the remaining 1879?
I'm not going to argue that there are still too many unresolved bugs. There are. However, there are several facts that seem to be overlooked, ignored, discounted, or chosen selectively by some: 1) RQCC is not authoritative. - There are many open reports that are fixed but not actually marked as such. - There are many reports miscategorized. Such as those marked critical just because someone thought this would get more attention or was critical *for them* but are not actually critical in the sense of data loss or crashing. - Not all bugs are created equal. Some affect most users; some affect only a small number of users. Choosing what to work on first is part of the quality improvement process. - A substantial number bugs are discovered and fixed within the development process without ever being reported in RQCC. - Human/time limitations have prevented 100% comprehensive logging of activity in the system. Engineers have looked at issues that are still marked unconfirmed for example. There is steady effort to improve on this aspect. 2) No one ever said we're done. - The version is 2.8.1 not 2.9 - Linux support has been going on quietly behind the scenes throughout the open beta period. Many bugs are caused by code which is specifically being targetted for Linux, and those will resolve with the new engine. It makes no sense to fix/test those changes twice. - Many other generic bug fixes -- ones that do not depend on Linux specifically -- are still in process and will be seen over the next series of betas. - Even when version 2.9 is released, it will still have bugs. Every product more complex than a coffee mug has bugs. - Some bugs are next to inscrutable. All are submitted by users who do not have formal training in testing or bug reporting. Every report is a considerable effort to understand, reproduce, and research, even if it's written well. It's a significant effort to work through RQCC items no matter how you slice it. - The pace of bug fixing may not please everyone, but it is proceeding slowly and steadily. 3) Revolution 2.8.1 is a marked improvement over previous versions. - 240+, 430+, 753+ -- There have been a lot of numbers thrown around. Whatever number you choose for resolved/fixed bugs, it numbers in the hundreds. RunRev marketing materials use the most conservative number, by design. - The effectiveness of the process is best demonstrated by the perceived quality as reported by users. This has been overwhelmingly positive. - The surveys back it up in a more empirical way, with EVERY measurement showing a 15% to 20% improvement over the baseline Beta 1 survey, and in many cases far exceeding that. - More users than ever before, a solid majority, rate 2.8.1 as preferred over 2.6.1 (which I think is fair to say was the previous standard of stability). - The integration of the new externals, especially the Browser and Database facilities, addresses many enhancement requests and provides solutions to previously impossible needs. They are definitely about Quality. 4) The Open Beta process is working well and going in the right direction. - We have more users than ever enrolled in the RQCC. - Those users are more active than ever before, filing more reports and comments. - We have more beta testers than we ever have. Nearly 550, with more applications coming in regularly. - Those testers have had a longer test period -- nearly six months -- to work with the product than ever before. - The overwhelming majority of survey respondents rate the beta test emails (96%) and thoroghness of communications (87%) as Good or Excellent. - RunRev made a major investment of time/resources to dramatically improve the beta test experience with the release of the new RQCC at the beginning of the Open Beta. - Far from being secretive the RQCC is open to everyone, whether they are a paying customer or not, enabling the kind of review of warts we're seeing in this thread. 5) It is worthwhile to participate, RunRev is listening. - The RQCC is a friendly, usable system which essentially did not exist before Open Beta. (We had Bugzilla but that was virtually unusable.) - Engineers are more engaged in the bug reporting, research, feedback, and fixing process than ever before. - The Open Beta is an effective way to uncover problems in the software before major versions are shipped. It did not exist before November. - The surveys measuring satisfaction have never been conducted before. The results from survey #1 were eye-opening. The results from survey #2 are vastly improved, but still not where they should be. There will be additional betas and additional opportunity for constructive feedback that is truly read and considered. - We've never before asked a large group of users to submit their Top Five issues directly to a human without going through the bug reporting or voting rigmarole... but that's exactly what we did with the Open Beta group. - It is RunRev
