On Fri, 31 Oct 2003 20:37:18 +1000 mlivingstone <[EMAIL PROTECTED]> wrote:
> 19:07:53: Error: Please specify at least one "To:" or "Newsgroup:" > recipient! I have just fixed it. I probably forgot to "make install", so I tested old version. > 19:04:02: Debug: .src/gui/wxComposeView.cpp(2811): assert > "wxAssertFailure" failed: shouldn't be called if we had been already > changed! I get this time to time, but I never figured out what triggers it. I'll try few more times today. > I have noticed in the past few weeks that we seem to be suffering from > a lot of silly little bugs that get fixed with 1-3 lines of code. Now, A lot? > In future, nobody should commit any code unless they can successfully > send a message with M configured / make / make install with their code > running. I've done that and I do it all the time. I am faulty human and I forgot "make install". I should change my practices and test uninstalled version. > ISTM that this would have avoided all of these composer bugs > lately. I would like your opinions on this and I would like to hear > what other ideas people can come up with to stem the tide of bugs > being reported as compared to the number fixed. Peer review (by other programmer who understands the code) would catch it, but it is hard to organize when people tend to be unavailable for weeks. > I know that since I > joined as QA person, we have had >50 bugs added to the bugzlist and > nowhere near that fixed Note that we don't keep track of all bugs in our sources. Anybody sitting down and testing can generate one bug report every 15 minutes. Bug database would explode if we collected all bugs, although it's true that no more bugs would be reported then. Also note that many of "bugs" that I have added are really just enhancements or they ask for considerable rewrites. On the other hand, we have this messy problem with wxWindows. wxWindows is buggy due to its infinite scope, dependency on uncontrolled platform toolkits and lack of developers. Our quality is limited by quality of underlying components. > I accept we will always have bugs - that is the nature of software - No, it isn't. It's possible to develop bug-free software. It's just that a lot of software doesn't "meet user expectations" and this is often more important than bugs. > but I am wondering if what we need is a milestone in the near future > where no features may be added but only bugs fixed. IMO more than half of effort goes into bugfixes already. There is still this possibility to disable/bypass all broken features... But I am not sure who would tolerate mailer with no internationalization, no addressbook, and no internal editor. Meeting user expectations is important. > Now I am not trying to rain on anyone's parade - I know we all do this > in addition to real life. I'm just wondering if there are any ways we > can increase the quality? Well, I am now shifting my attention towards quality, but for different reason than you. I am worried about my productivity. I often spend several hours proving to myself that there must be a bug in what I am using, then hours looking for it, then hours arguing with original developer that it really is a bug. Only then my 3-line patch is committed. Then there is all this time wasted creating workarounds and recovering from bugs in software that I am using. Unfortunately, there is this problem that quality of software is limited by quality of its platform. I am not sure whether I can get past good development tools. Mahogany will see very little of this effort. Of course, meeting user expectations is what software is here for, so I am going to work on this once I get past wasting mine and user's time. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
