I should have been clearer: I'm not so worried about the syntax, so long as https://mozilla-releng.net/trychooser/ still exists. What's unclear to me is the revision management/selection side of things.
Nick On Sat, Sep 16, 2017 at 9:57 AM, Kris Maglione <kmagli...@mozilla.com> wrote: > `mach try` is basically just a wrapper around try syntax, with the added > ability to specify paths to directories you want to add tests for. It > suffers the same lack of documentation that try syntax in general does. > > Trychooser now generates `mach try` command lines in addition to commit > message syntax, so given that try syntax is supposed to continue to work > with `mach try`, I don't see why trychooser wouldn't. > > > On Sat, Sep 16, 2017 at 09:51:41AM +1000, Nicholas Nethercote 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 >> > > -- > Kris Maglione > Senior Firefox Add-ons Engineer > Mozilla Corporation > > He hoped and prayed that there wasn't an afterlife. Then he realized > there was a contradiction involved here and merely hoped that there > wasn't an afterlife. > --Douglas Adams > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
