On Sun, Feb 3, 2013 at 7:59 AM, janI <[email protected]> wrote: > Hi. > > First let me congratulate QA in general for the big job you all are doing, > and especially all the new volunteers are really helping ensuring AOO gets > more stable. I have big confidence that our upcomming release will show > stability from day one, and not as many open source products, need a patch > day two. > > I have one concern (which might be false) that when bugs are rejected or > confirmed as resolved it may be done on non releases. > > Let me explain, I have just been searching for a problem regarding use of > text string in AOO (l10n basically), having isolated and solved the problem > I wanted to debug it, and being a big lazy I used minimum configuration > switches. I debugged the problem and was pleased that it was solved, > however when I configured again with the full set (I try to configure as > close to release switches as possible) the bug reapeared. > > So when rejecting a bug or confirming that a bug is solved, we should > ensure it happens based on an identfiable configuration. For all QA > volunteers that uses a downloaded image this is not a problem, is is solely > a potential problem for those who debug and therefore build AOO locally. >
This is a good reminder. Thanks. One extra check we can do is after we reach "feature freeze" for AOO 4.0, we should have one or more "regression test passes". In those test passes we could re-test the bugs that are claimed to have been fixed in 4.0. That way if someone was fixed in a snapshot build but later broke again, we will catch it. I remember reading an analysis that looked at bug origins and found that 25% of defects were side effects of fixing other bugs. So a large number of fixes also automatically means there is an increase in the number of new bugs. -Rob > At the moment we have not documented how to build AOO equavilent to the > downloable binary image, something I hope will change in the future. > > Thx again to all in here and pls. keep up the good work. > Jan I.
