Posted by: Anonymous Coward
on March 14, 2007 11:11 AM
I have been party to various bugs and the processes various OOS projects have to report bugs. I find that OSS has no displine for the basics of Software Quality Assuarance and in fact there is no displine in this regard. This has been the subject of so many discussions in articles like these and/or the actual mailing lists of many major projects.
Case in point the issue of memory problems of one cornerstone large OSS project were reported over 3, perhaps 4 years ago for issues that had been ongoing for over 2 years before that. Serious memory leaks that also put the same key software at serious security risk not to mention the major strain it places on the Operatings Systems. The response to the bug reports was they were aware and working on it. The problems progressed to very severe instead.
Now over the past year memory problems are listed fixed as security related issues are cited as reason for the security fix, yet for a few months the memory problems still progressed much worse. Then the serious worse issues appeared to be fixed, but the core issues that have been about for over 5 years remain.
To really see how uncommitted many of the key OSS projects are to bug fixes just look a the bug reports, how long the bug reports stay open, the soap opera the bug reports take on and the attitude of those reviewing the bug reports. While I appreciate there are those bugs that are not well definied or supported with facts, there are many that are. Those that well defined and reported drag on and on and on.
Personally as a QA Specialist with many years of experience I gave up reporting OSS bugs/issues. Those I did report I abandoned as the attitude, soap opera, lack of maturity, inability to discuss facts was just a waste of my time. The icing on the cake was I was told by the buglist moderators I would have to put up with the gross lack of maturity. That for me was the proof that I was wasting much of my time that could be more productive on other tasks I had and/or me taking on code when I could to sort out some of the issues myself.
Some may ask me I should contribute the fixes back. I tried that and gave up on that as again the patch was riddled with opinions if was coded correctly, if meets the personal coding standards of the lead project developer, and generally complain about the code is not fixing anything. So I do not provide any of the code fixes I spent weeks or months figuring out when a project developer could effect the code cahnge in a hour or two. Remember I am not a developer so I cannot figure out the more complicated deep in code across many lines of code problems. My code is good as I am used to coding from my assembler coding experience.
I know there will be many that disagree with my opinion. That is your right to do so. Am I the last authority about QA Testing? No. I will leave my experience and knowledge at that.
I will say this in closing. I have used OSS and Linux for over 7 years. I am not a Windows fan. That said I can say that sadly there are far less commerical programs with the severe problems that plague many of the key OSS projects. I am very tired of the "attitude" of these people that know that there is no problem. Even worse when the facts are conclusive they will blame some other software. For some problems I have managed to find in the code where the problem is and fix it. I am not a developer so it takes me much more time to get to know and understand the code to find out where the issue is. It is amazing how basic some of these bugs are and their root cause. What may take me weeks or months to figure out I am sure a project developer would be able to find and fix in hour or less for most of the bugs I have fixed.
I have had some good experiences with a rare handful of OSS persons and/or projects. In my experience when one has such rare people involved in the bug screening, reporting and validation process the project gains. The problem is that most OSS projects do not have such people and they often are only part of the project for a short time. It is such a shame as the whole experience is enjoyable, and in end either results in a fix or understanding why this may not be a bug, future feature to be worked on, or limitation. Even if it takes much time in terms of testing, doing what is asked to try to add information for the QA Gatekeeper to evaluate the issue it is ok. Sometimes not convient, but that is ok, at least the activity makes sense, is objective and enables all involved to be productive.
No Serious Comittment to Testing/QA by Major OSS
Posted by: Anonymous Coward on March 14, 2007 11:11 AMCase in point the issue of memory problems of one cornerstone large OSS project were reported over 3, perhaps 4 years ago for issues that had been ongoing for over 2 years before that. Serious memory leaks that also put the same key software at serious security risk not to mention the major strain it places on the Operatings Systems. The response to the bug reports was they were aware and working on it. The problems progressed to very severe instead.
Now over the past year memory problems are listed fixed as security related issues are cited as reason for the security fix, yet for a few months the memory problems still progressed much worse. Then the serious worse issues appeared to be fixed, but the core issues that have been about for over 5 years remain.
To really see how uncommitted many of the key OSS projects are to bug fixes just look a the bug reports, how long the bug reports stay open, the soap opera the bug reports take on and the attitude of those reviewing the bug reports. While I appreciate there are those bugs that are not well definied or supported with facts, there are many that are. Those that well defined and reported drag on and on and on.
Personally as a QA Specialist with many years of experience I gave up reporting OSS bugs/issues. Those I did report I abandoned as the attitude, soap opera, lack of maturity, inability to discuss facts was just a waste of my time. The icing on the cake was I was told by the buglist moderators I would have to put up with the gross lack of maturity. That for me was the proof that I was wasting much of my time that could be more productive on other tasks I had and/or me taking on code when I could to sort out some of the issues myself.
Some may ask me I should contribute the fixes back. I tried that and gave up on that as again the patch was riddled with opinions if was coded correctly, if meets the personal coding standards of the lead project developer, and generally complain about the code is not fixing anything. So I do not provide any of the code fixes I spent weeks or months figuring out when a project developer could effect the code cahnge in a hour or two. Remember I am not a developer so I cannot figure out the more complicated deep in code across many lines of code problems. My code is good as I am used to coding from my assembler coding experience.
I know there will be many that disagree with my opinion. That is your right to do so. Am I the last authority about QA Testing? No. I will leave my experience and knowledge at that.
I will say this in closing. I have used OSS and Linux for over 7 years. I am not a Windows fan. That said I can say that sadly there are far less commerical programs with the severe problems that plague many of the key OSS projects. I am very tired of the "attitude" of these people that know that there is no problem. Even worse when the facts are conclusive they will blame some other software. For some problems I have managed to find in the code where the problem is and fix it. I am not a developer so it takes me much more time to get to know and understand the code to find out where the issue is. It is amazing how basic some of these bugs are and their root cause. What may take me weeks or months to figure out I am sure a project developer would be able to find and fix in hour or less for most of the bugs I have fixed.
I have had some good experiences with a rare handful of OSS persons and/or projects. In my experience when one has such rare people involved in the bug screening, reporting and validation process the project gains. The problem is that most OSS projects do not have such people and they often are only part of the project for a short time. It is such a shame as the whole experience is enjoyable, and in end either results in a fix or understanding why this may not be a bug, future feature to be worked on, or limitation. Even if it takes much time in terms of testing, doing what is asked to try to add information for the QA Gatekeeper to evaluate the issue it is ok. Sometimes not convient, but that is ok, at least the activity makes sense, is objective and enables all involved to be productive.
#