Vincent Povirk wrote:
Your model makes bugs that show up in only a few applications very rare. I've added some to your existing model with duct tape. I arbitrarily decided that about 40% of apps would have 1 or 2 unique bugs, in addition to the current ones.
You can better model this by just changing the probability distribution of the various bugs and using the "alternate" method where each bug has an absolute probability of affecting a given app. Then make about 1000 bugs have .05% probability or so, and odds are most of them will only affect one or two apps (if you have 2500 you're modelling)
The result is an exponential curve, until about 80% of apps are solved. After that, the curve is linear. This makes a sort of sense. If we do it right, we're likely to fix the bugs that affect a lot of apps before we finish with the ones that affect one or two. Once the major bugs are fixed, Wine and Windows become comparable to a more "normal" set of different interface implementations: largely compatible, but a few developers will continue finding subtle differences to rely on forever. The rate at which apps hit these differences should be fairly consistent. I do wish I had a better way to do this than tacking it on to the existing stuff. I think I broke pickNextBug, but fortunately that's unused until all apps are solved. If you increased the number of very rare (1 or 2 apps) bugs in a less crappy way, it might show something smoother.
I'll try my suggested method now.
I have a feeling that in general the exact shape depends mostly on how likely it is for a bug to occur in multiple apps and on how many bugs each app has. If a typical app has only a few bugs (the constants you've chosen imply that it doesn't), things look very nice at the start. If a typical bug affects many apps (the constants you've chosen imply that it does), things look very nice at the end.
Yeah, I'll note that whether a typical app has a few bugs or a lot of bugs to start with depends on whether we want to model "from the start" or from here on out.
Thanks, Scott Ritchie
