On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc <g...@mozilla.com> wrote:
> 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).
>
But the cost of that is imposing cinnabar on everyone who wants to use git.
This is bad for several reasons:
1. Custom tools are bad (incidentally, this is also an argument against the
machization of everything, but that's perhaps for another day)
2. There are a lot more people writing code for Firefox than developing the
internal tools, so in general, costs on those people should be avoided.
Moreover, the trend here is to support native *git*: Phabricator doesn't
require hg (at least it shouldn't; it certainly doesn't when we use it for
NSS) and as we move away form having people do direct pushes to the repo,
then they won't need cinnabar to land code either. So, having try be about
the only place where where you need cinnabar is bad.
> 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.
>
This is not a good decision making procedure. First, requiring people to
volunteer their objections inherently underweights those objections because
it's work to do so. Second, the current situation has incentivized people
to use cinnabar, so the number of vanilla git users is less than it
otherwise would be. But this is bad, for the reasons I listed above. The
right question is: what future do we want to live in, and that's a policy
question, not one decided by taking a (highly biased) poll of what people
currently do.
-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
