![]() □ □ □ Shit happens, and it’s good you recalled.įor hours, mostly after completly setting up my Zibo to now contact online-atc being “ready for push” I … entered my email-address and sent the bug-report □ Should have kept the mailaddress in the clipboard, haha. So you would be able at once to sort what is related to system issues, and what is related to ecosystem issues ? Perhaps you could build a small controlled sample (200-400 volunteers) composed by 60% of people known to run a “clean” system on the different OSs, and 20% running with plugins, 20% with “exotic” systems (low specs, multiscreen, heavy multiplayer, very personal input devices …). In my opinion the 2 tiered system would make the most sense, especially if you can control who is targeted at first. That is what I also saw in the few logs which have been posted in the last hour on the. ![]() However there is also a given, a lot of people jumping into the beta run are those craving for performance because they run a lot of plugins and are completely oblivious to the idea to remove them before testing. So it is probably a good idea to test on a small sample first. Should we test in tiers ? Interesting question.Īs with previous beta runs, there is a pattern, beta good, beta well uh you know. If you are reading this blog post, this far down, you are probably participating in the beta I’d be curious what approach you’d find most useful. (This practice is actually industry standard on mobile apps.) 10% of users get notified immediately, then another 40% if we don’t see crashes, then the last 50%. Send out the beta update notifications over time, e.g.Early adopters could get an email and hand-update to the new beta before it is put out for auto-update notification. So we thought about two possible ways to do this: We need beta victims^H^H^H^H^Htesters to find these bugs, but once we get a dozen crashes, we don’t need anyone else to stub their toe for us to fix our problems. This came up in our impromptu beta five post-mortem meeting: do we need to bring people into new betas in stages? With code for new drivers, beta five probably won’t be the last beta where we code something we think is helping and discover that it fails catastrophically, but not on our hardware. Moving to a new driver stack has meant learning about the weird things that happen on your computers and not ours. But we also have probably a dozen PCs total we can run on. Steam Users: we did not release the beta five build to Steam and this is probably a good thing we’ll try again with a new release that isn’t made of plutonium and unicorn hallucinations.Īnd if you’re going “why didn’t y’all test it before you released it”…we did! None of our machines show these crashes. ![]() ![]() We have enough captured crash data to investigate. Please stand by and keep flying beta four we’ll post a new beta when we’ve gotten to the bottom of this. ![]() If you were not auto-notified to update to beta five, that’s probably for the best. Laminar Installer Users: if you were auto-notified to update to beta five and did so, and you are not crashing, you can keep flying! If your beta five is just a smoldering wreckage of crumpled VRAM and GPU parts, you can re-run the installer with “get betas” option checked, and it will take you back to beta 4. I hit “go” on the release this afternoon, and half an hour ago, I hit “ stop.” The auto crash reporter was showing way too many new crashes in memory management that we had not seen before, and this strongly implies a new and serious bug. Cool new technology! Big bug fixes! Lots of winning!Īs it turns out, beta 5 is dead. A lot of stuff that we thought was pretty good went into beta 5. I was going to write a post about X-Plane 11.50 beta 5 – what’s new in it, the new ways we are debugging GPU crashes, the crash bugs we’ve fixed, etc. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |