We don't have any sort of QA report on the latest build. DIGY called for testing, but I haven't seen anyone respond to that request indicating successful testing.
So, how do we want to manage this? In the business world, we'd never think of making a release without extensive QA first. In my other open source projects, either we've managed QA ourselves by 'switching hats' for a couple weeks prior to release, or just crossed our fingers because the user base was too small. Lucene.Net is a fairly high-profile project, with a large user base. I think it would not be responsible to make a release without a formal QA process. We do have extensive unit tests, but do you think those are sufficient to cover our QA needs? Should we try to find community members with a specialty in software testing that would be willing to fulfill this role on our project? Should we just swap hats? I didn't worry about this issue with the latest 2.9.2 release because it was QAed by the user base for a long time before it was an 'official release'. Maybe this is an effective tactic? Release first, and let the user base roll in bug reports fixing them on yet later minor maintenance releases? This seems to be the method a lot of projects use (i.e. no specific QA process, but rather an organic process of 'try our best then deal with bug reports later'). What do we think about this? Thanks, Troy On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <[email protected]> wrote: > > Hey all, > > I know we have a number of outstanding JIRA issues, but I think most of them > have been handled for the 2.9.4 release? Do we have anything outstanding that > is holding back a new release? > > ~P
