Paul Luo Li wrote: > Thank you very much for your response. > > By "field defect" I mean a bug in the Bug Database. > > I was wondering if you think predictions at the time of release of the > number of field defects in each month after release can help: This is going to be highly dependant on what codes changes were made for that release. Some metrics (number of changes, number of changed files) are easy whereas others (criticality of code changes) are much harder.
> -allocate resources, such as having enough people available to fix problems There is no allocation of resources in open source. Each committer works (or doesn't) on what they feel like / have time for / care about. > -adjust the deployment date, like pushing back the release, or If you can get the prediction working accurately... > -identify possible ways of improving the process, assuming that the > predictions are made using software metrics, such as the number of changes > to the code The only change I can see right now might be how long we wait between releasing an alpha/beta and voting on its stability. You wouldn't need prediction for this, just a graph of number of open bugs against time with the releases and stability votes marked. Good luck with the research, Mark --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
