On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc <g...@mozilla.com> wrote:
> On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> What happens if you are using git?
>>
>
> git-cinnabar is already supported.
>
Supported how? Do I have to have special remote names? Special refs? Or
does it mess with my git config?
> Vanilla git is TBD. I see bug 1400470 was just filed for that.
>
Having this fixed seems like a blocker.
-Ekr
>
>
>>
>> On Fri, Sep 15, 2017 at 3:30 PM, 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
