jugglinmike

> @jugglinmike are the crashes still persistent with the latest Nightly build of Firefox? Unfortunately, yes. @whimboo provided some more detail on crash recovery in gh-602. I'd like to respond...

> Lots of starts of Firefox take about 20s and more!! And we have lots of > those. Most restarts documented in the complete log are expected. As I mentioned...

Thanks for the link--it's good to know I'm not alone! That's also the reason I don't think we can consider @jgraham's patch a resolution. I'd like to help resolve the...

Thank you for this; it wasn't obvious to me at all. I agree that the bug should be fixed, though I disagree with the classification of "exotic" (Ubuntu's LTS lasts...

Our options depend on how widely you define the term "configuration". That might include: - Process level - Browser version (for F/OSS browsers) - Command-line flags - Environment variables -...

> What could a solution for this in the wpt CLI look like? Would it be such > that upgrading the nightly browser version is a PR on wpt? I...

Because @foolip made the mistake of complimenting my ASCII "art" in a recent presentation, I'm going to try to explain this with dashes and pipes. For context, the current system...

> The main complication that introduces is how long-lived that "somewhere" storage needs to be. I've been considering that storage to be *the* canonical location for WPT results data. In...

That sounds good to me! Today, we only have one data source (the test runner in the `run/` subdirectory) and one consumer (`wpt.fyi`). When we have more sources of data,...

With commit 84486a4fbf98e936618e1ff5e6ce808c79bbf877, I re-introduced the "retry" heuristic that we initially implemented in the previous infrastructure. With this patch applied, the system attempts to recover from intermittent failures by re-initiating...