Yes, we'd like to make it the default eventually. I've been holding off for now, but expect it will be switched to the default at some point in Q4 or Q1. If you don't want to wait and are tired of typing 'fuzzy' each time, you can create a ~/.mozbuild/machrc file and add: [try] default = fuzzy
On Fri, Sep 15, 2017 at 7:54 PM Bobby Holley <bobbyhol...@gmail.com> wrote: > FWIW, I've found |./mach try fuzzy| to be very intuitive and kind of the > best of both worlds for command-line vs GUI. I don't know what the > non-fuzzy version does, but perhaps fuzzy should be the default. > > 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. > > > > 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. > > > > Nick > > > > 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 > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
