Confirmed users
328
edits
Bent.mozilla (talk | contribs) |
|||
Line 18: | Line 18: | ||
* (mrbkap) The ability to cancel a try server run once it's started would be useful. Especially after seeing some failures, I often notice that my patch is wrong in some way, and I don't want to continue to receive e-mails or see more results until I fix my patch and push again. This might also help me use less resources whenever I push to try. | * (mrbkap) The ability to cancel a try server run once it's started would be useful. Especially after seeing some failures, I often notice that my patch is wrong in some way, and I don't want to continue to receive e-mails or see more results until I fix my patch and push again. This might also help me use less resources whenever I push to try. | ||
* (bent) I'd love a link to the tinderbox log in the success/failure emails that get generated rather than a simple "go check tinderbox" link. Sometimes I have a hard time finding the logs that I'm interested in. | * (bent) I'd love a link to the tinderbox log in the success/failure emails that get generated rather than a simple "go check tinderbox" link. Sometimes I have a hard time finding the logs that I'm interested in. | ||
* (sfink) use ccache on the try build boxes, to win back some of the time lost because of clobber builds. | |||
* (sfink) report the change id in the build, test, perf logs. | |||
* (sfink) ''TBPL'' - when displaying the changes for a particular push, show everything that doesn't exist in a "main" tree (m-c, TM, etc.) Highlight the ones that are being shown now (which I assume are the ones that are new to the try repo.) (This is probably more difficult than it's worth.) | |||
* (sfink) Job control UI: after pushing, be able to visit a web page specific to your push. Show the dependency graph of all current and potential jobs. Be able to blast away existing ones (eg builds on unwanted architectures) and enable others (eg Talos runs assuming they are disabled by default.) | |||
* (sfink) When pushing, have an option to do a "dependent" job graph: instead of starting everything up in parallel, pick one build (possibly by architecture, possibly by the fastest available builder, possibly random) and make the other builds dependent on its ''success''. Do the same with the tests. This is for reducing wasted resources when either (1) the developer doesn't mind waiting longer for the results eg it's the end of the day or (2) the developer is uncertain whether it will build at all on some arch or with certain compile options. | |||
* (sfink) Export a $platform variable to the mozconfig-extra script for easier selection of specific platforms. (I know, my bug for this is WONTFIX because bigger better things are already underway, but I'm mentioning it for completeness.) | |||
* (sfink) Use distcc for the build boxes. Only useful if the load is currently unevenly distributed. | |||
* (sfink) Allow selecting subsets of tests. | |||
= Preventing you from using tryserver effectively for your needs = | = Preventing you from using tryserver effectively for your needs = |