On Fri, Sep 15, 2017 at 8:37 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
> 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?
>
It "just works." Git doesn't require remotes or tracking refs to do pushes
and the git-cinnabar `mach try` integration doesn't make meaningful (read:
outside of reflog) persisted changes to your repo state as part of doing
its job.
>
>
>
>> Vanilla git is TBD. I see bug 1400470 was just filed for that.
>>
>
> Having this fixed seems like a blocker.
>
Maybe. The policy is to support Git as a VCS tool for Firefox development.
Previously, git-cinnabar - but not vanilla Git - has counted. e.g.
git-mozreview and artifact builds require cinnabar. I would strongly prefer
to maintain the "support Git == git-cinnabar" interpretation because
otherwise we're looking at supporting N+1 tools (where the +1 for vanilla
Git is *substantially* more effort than the existing Mercurial +
git-cinnabar).
I'd prefer to take a data-driven approach to answering the question of "do
we need to support vanilla Git." I wish I had local developer metrics or
results from a recent developer survey to feed into a decision. In lieu of
that data, I'd encourage users of vanilla Git to make noise on bug 1400470
if you feel you need `mach try` support.
>
>
>>
>>
>>>
>>> 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
