On Fri, Sep 15, 2017 at 4:51 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote:
> Are there docs on how to use `./mach try`? `./mach help try` doesn't give > much detail. > `mach try` has sub-commands. Run `mach help try syntax` and `mach help try fuzzy` for more useful docs. The former is actually a pretty reasonable documentation of Try Syntax. There is some light magic where `mach try <args>` is essentially treated as `mach try syntax`. This could be documented better in `mach help try`. > > Also, will https://mozilla-releng.net/trychooser/ still work? I'm > generally more of a command line person than a GUI person, but this is one > case where I find the GUI approach far more usable. > I reckon it will. Although with the velocity that Try Syntax changes, it is arguably better to have this all in-tree. Also, it is kind of silly that you have to open a web site and copy something from that into your terminal. IMO this should all be turnkey. e.g. `mach try chooser` would start a local HTTP server, point your web browser at it, and an HTML form submission would stop the local HTTP server and submit to Try. That feels a bit more pleasant (for those who can run a browser in their development environment anyway). But I digress: that site should continue to run. > > On Sat, Sep 16, 2017 at 8:30 AM, Gregory Szorc <g...@mozilla.com> wrote: > >> The Try Service ("Try") is a mechanism that allows developers to schedule >> tasks in automation. The main API for that service is "Try Syntax" (e.g. >> "try: -b o -p linux -u xpcshell"). And the transport channel for making >> that API call is a Mercurial changeset's commit message plus a version >> control "push" to the "try" repository on hg.mozilla.org. >> >> As the recent "Reminder on Try usage and infrastructure resources" thread >> details, scaling Firefox automation - and Try in particular - is >> challenging. In addition, the number of workflows and variations that >> automation needs to support is ever increasing and continuously evolving. >> >> It shouldn't come as a surprise when I say that we've outgrown many of >> the implementation details of the Try Service. Try Syntax itself is over 7 >> years old and has survived a complete rewrite of automation scheduling, for >> example. Aspects of Try are adversely impacting the ability for developers >> to use Try efficiently and therefore undermining our collective ability to >> get important work done quickly. >> >> In order to put ourselves in a position to more easily change >> implementation details of the Try Service so we may deliver a better >> experience for all, we'd like to require the use of `mach try` for Try >> submissions. This will ensure there is a single, well-defined, and >> easily-controlled mechanism for submitting to Try. This will allow greater >> flexibility and adaptability. It will provide better opportunities for user >> messaging. It will ensure that any new features are seen by everyone >> sooner. It will eventually lead to faster results on Try for everyone. >> >> Bug 1400330 ("require-mach-try") is on file to track requiring `mach try` >> to submit to Try. >> >> The mechanism for submitting to Try has remaining relatively stable for >> years. `mach try` is relatively new - and I suspect unused by a sizeable >> population. This is a potentially highly disruptive transition. That's why >> we're not making it immediately and why we're sending this email today. >> >> You can mitigate the disruption by using `mach try` before the forced >> transition is made and reporting bugs as necessary. Have them block >> "require-mach-try" if you need them addressed before the transition or >> "mach-try" otherwise. We don't really have a good component for `mach try` >> bugs, so put them in TaskCluster :: Task Configuration for now and chain >> them to a tracking bug for visibility. >> >> FAQ >> >> Q: When will the transition be made? >> A: When we feel `mach try` is usable for important workflows (as judged >> by blockers on "require-mach-try"). Also, probably not before Firefox 57 >> ships because we don't want to interfere with that release. >> >> Q: What about old changesets? >> A: You will still be able to submit to Try using the current/legacy >> mechanism for old changesets. There will be a "flag day" of sorts on >> mozilla-central after which all Try submissions will require `mach try` or >> nothing will get scheduled. >> >> Q: Will Try Syntax continue to work? >> A: For the foreseeable future, yes. There is a long-term goal to replace >> Try Syntax with something more automatic and less effort - at least for >> most use cases. But there are no definite plans or a timetable to remove >> Try Syntax. >> >> Q: Are there any other major changes planned? >> A: Several. People are hacking on path-based selection, `mach try fuzzy` >> improvements, moz.build-based annotations influencing what gets scheduled, >> not using a traditional Mercurial repository for backing Try, and more. >> Some of these may not be available to legacy Try submission workflows, >> giving you additional reasons to adopt `mach try` sooner. >> >> Q: Should I be worried about this transition negatively impacting my >> workflow? >> A: As long as you file bugs blocking "require-mach-try" to make it known >> why `mach try` doesn't work for you, your voice will be heard and hopefully >> acted on. So as long as you file bugs, you shouldn't need to worry. >> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
