>From: Marcin Miłkowski <[EMAIL PROTECTED]> >Sent: Mar 16, 2007 7:18 AM >To: [email protected] >Subject: Re: [qa-dev] Nearly 1000 unconfirmed defects are open! > >Hi Mike and all, > >I can understand some frustration with QA and overall with bug fixing >process. There are buggy features which are sometimes left as are for >many years (limitations of regular expression search & replace was just >such a feature for some years, to be started only two weeks ago...). > >So let me rant as a developer. > >Recent changes in patch handling processes seem to make the work of QA >and community developers easier. It's quite hard to change C++ code in >OOo - you need to setup the build environment, and in some OSes this >requires buying a lot of proprietary stuff (gcc is only starting to be >used, right?), and of course you need a lot of time etc. The process >isn't really modular.
First, gcc has been used for a long time in the UNIX/Linux builds and has created problems of its own. For the Mac OS X build, all that has been available, to my knowledge, is gcc or a derivative. Second. OpenOffice.org is far from completely modular but it is better than most products of its size. At least you can figure out the down- stream problems and the usage of Namespaces. > >But it's pretty easier to start working on script components - for >example, I fixed ugly bugs in a python script for e-mail merge, and in >two or three weeks they have been integrated into a bug fixing cws. The >script is still buggy (but usable at least) -- however, I need some >additional features which do not work as expected so probably I will fix >other bugs with this in the future. I already invested some 20 minutes >in that, and I'm ready for another 40 minutes to fix this ;) > Correct. It is much easier to fix scripts and that is a good place to start. Since I am deeply involved in the QA process, I decided that the automated testtool product needs to be cleaned up and moved from German to English. Is this an easy task? No. Is it a pretty task? No. Is it needed and essential for proper testing of OpenOffice.org? Yes. >This means that if it was easier to work modular, without compiling all >the stuff, and knowing all APIs, SDKs, etc., we'd have more developers. >This way we could manage the development of the complex system much >better. I don't know how to make the core code more modular, so this is >only ranting. > Modularity is a goal, seldom achieved in the 'real world' where folks are paying for the product and thus for development. However, that does not mean that we can make OpenOffice.org better. STL and Boost are two great timesavers, if they are used properly. It looks like the development team has a good grasp on this and OpenOffice.org has benefited from this. James McKenzie QA Team and Mac OS X QA Testing Coordinator --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
