Thank you very much for the response. By "field defect" I mean a PR in the Bug Tracking system of the Class sw-bug.
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: -allocate resources, such as having enough people available to fix problems -adjust the deployment date, like pushing back the release, or -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 Thanks Paul > -----Original Message----- > From: Theo de Raadt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 24, 2006 2:25 PM > To: Paul Luo Li > Subject: Re: What would you do with field defect rate predictions? > > > I have been examining OpenBSD bugs and have been looking for ways of > > predicting the field defect rate, that is, predicting at the time of > release > > the number of field defects in each time interval after the release. I > am > > brainstorming possible applications for this research. > > Hmm. > > > I was wondering what you all think OpenBSD can do (or do better) if it > had > > field defect rate predictions. Your input would really give my research > a > > reality check. > > I don't see how it can help. I don't know what "defects" you are > measuring. > > If you are measuring what we release as "important fixes for users", > then that is an weak measurement because we make decisions on what to > release along many axis. Often we do not release critical stuff > because it may be too integrally tied to other parts of the system. > Sometimes it is about convenience. Sometimes it is about > > If you are measuring what users report as bugs in our bugs database, > that also is subject to many errors. Many bug reports come to us in > other ways, too. > > A more accurate assessment would be all commits which "fix a bug that > was in the previous release"; but that is hard to judge because we mix > our new development with our repair development. > > I dunno. I don't see how knowing the rates can change anything. > > If the rates are determined by anything, it is this: how agressive > are we to push new features into our tree, which may still have bugs. > > And the problem is that since it is volunteer organization I kind of > must let people do some live development in the tree, and there will be > some fallout... > > I don't know how knowing any stats can change that.
