Open Bug 1261944 (awesome-try) Opened 5 years ago Updated 2 years ago
[meta] Tracking bug to make interacting with try server awesome
This effort originally came out of the desire to make debugging test failures easier. There are two ways to approach this problem. A) Improve local debugging support (gdb, rr, valgrind, etc.) B) Improve remote debugging support (logs, loaners, ssh/vnc based solutions) Both these approaches are very important and worthy of time and effort. But we decided to focus on B) for several reasons: * Based on a survey we sent out to developers last August, the most common theme by far was frustrations with try. * Improving try helps everyone no matter what platform they use, whereas improving e.g OSX local debugging only helps people who have a mac to develop on. * Local debugging is an itch that gets scratched from time to time by developers themselves. Whereas no one will focus on try improvements if not the ateam/releng. So I started thinking of ways to make debugging test failures on try easier, and came to a realization: this problem is extremely vague and there is an entire range of improvements that can be made that aren't directly related to debugging, but that can make debugging easier. For example, reducing the time it takes for a failure to surface makes debugging easier as you can iterate quickly, keeping pertinent debugging information fresh in your memory. Then I thought, there are already methods to iterate quickly on try, but they aren't widely used because either people don't know about them, they are sort of flaky or they are hard to use. So now one can argue that UX/useability also improves debugging on try. This kind of ballooned for awhile until I concluded that not only should debugging test results on try be easy and awesome, but that the entire overall experience of interacting with try should be easy and awesome. This is no small feat and spans many different sub-projects that have the potential to take quarters of time themselves. This bug will track all the projects and changes we can think of that will help make interacting with try awesome. They will span many different projects and vary widely in time to completion. Not all of them will be high priority enough to receive attention. The end goal is to build a comprehensive dependency tree filled down to all the actual units of work, complete with time estimates for each piece. This will hopefully help us look at the big picture, while letting us drill down enough to help us determine what to prioritize. Finally, because "improve ability to debug test results on try" sounds really boring, and because most improvements at least indirectly impact this, I re-branded this effort to "make try awesome".
Component: General → Try
Product: Testing → Firefox Build System
You need to log in before you can comment on or make changes to this bug.