On Fri, Sep 15, 2017 at 4:48 PM, Nick Fitzgerald <nfitzger...@mozilla.com>
wrote:

> Does `mach try` still require `git cinnabar` when using a `git` checkout
> of m-c, or does it work with `moz-git-tools` now too?
>

It currently requires git-cinnabar. TBH, I forgot about this. Supporting
non-cinnabar will be a bit annoying. Not impossible, but annoying.

A non-cinnabar user should file a blocking bug detailing their workflow so
we can figure out a path forward. It is quite possible the outcome is "only
support git-cinnabar." So whoever files the bug should reply here with the
link so non-cinnabar Git users can pile on and let your numbers be known.
But please do it in the bug and not on this list.


> 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

Reply via email to